【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

快猫来炜:如何端好运维的饭碗

  • 2023-03-11
    北京
  • 本文字数:3794 字

    阅读完需:约 12 分钟

快猫来炜:如何端好运维的饭碗

作者的话:我们观察到:国内运维行业,不同的公司做法差异巨大,从业人员水平参差不齐,缺少普遍性行业认知,难以形成合力(这也会让 To B 的产品异常难做,不利于行业整体发展),甚至在部分公司,运维人员处在技术鄙视链最底层,我们希望为行业带来一些新的思路和发展推动力。


这需要很多行业老炮一起,输出观点,共同碰撞,才有可能形成一些先进的共识,形成行业前进的思想旗帜。所以,我们准备策划《运维百家讲坛》这么一档栏目,诚邀 100 个运维总监(或更高)级别的老炮,通过采访或约稿的方式输出他们的观点,给行业一些借鉴。


讲坛第 1 期《井源:运维几何》和前段时间马驰的《是时候让运维集体下岗了》在业界引起广泛讨论,运维岗位真的没有前途了吗?如何把饭碗端稳?这一期,我们采访了快猫星云的来炜,来炜是运维破圈创业人士,既然能创业,一定是在行业内有很深的积累的,他会怎么看待这个问题?让我们一起来听一种新的声音!这里是接地气、有高度的《运维百家讲坛》第 3 期,开讲!

介绍一下您自己以及现在的公司?


大家好,我是快猫星云的来炜。快猫星云是一家云原生智能运维科技公司,由开源监控工具“夜莺监控”的核心开发团队组成。快猫星云打造的云原生监控分析平台——“Flashcat 平台”,旨在解决云原生架构、混合云架构下统一监控难、故障定位慢的问题。 如果想更多了解快猫星云创立背后的故事,大家可以进一步阅读 ITPub 对我的一个专访《十年死磕,从一线工程师到CEO》,欢迎大家指正。

有些运维老炮反映公司对运维的价值所知甚少,您是怎么给公司讲清楚运维的价值的?


把工作的价值,如何通俗易懂的给公司管理层讲清楚,并取得理解和支持,是所有中后台技术团队普遍面临的难题,否则失业分分钟的事情,运维工作的价值讲清楚更是难上加难。


从我的朋友圈来看,时不时就会看到劝运维下岗/转行的帖子:

  • 比如瑞典马工的《是时候让运维集体下岗了》,振聋发聩,开篇就提到:明人不说暗话:在云原生和 DevOps 成熟的今天,运维作为一个岗位和团队已经完成了历史任务,应该退出舞台了。

  • 再比如带我入行的井老板,在 SRETalk 第一期中,用心良苦的劝导:随着科技的发展,时代的变化,一个岗位的消亡是很正常的事情,及时做好调整和规划才是思考的重心。


但是,运维这个岗位以及背后的运维人,从来都是一次次站在要被淘汰的边缘徘徊,又一次次倔强的起死回生,柳暗花明。他们往往乐于自嘲、主动拥抱危机、敢于求变。回想下,近十年来,云计算也好、云原生也罢、DevOps 也算,SRE 也行,所有这些 IT 的大变革,都是尝试在不断优化和改进“大运维”这个领域。运维这个行业没有消亡,反而是不断进化,生发出了新的内涵。


这说明了什么?说明运维很重要,说明运维也很难!但是如何把这个价值说清楚,我们从站位、目标设定、投入产出比上来分别着手分析。

您觉得运维工作最重要的几个目标是什么?您是怎么落地这些目标的?运维的价值如何更好的得到体现?

聚焦经典的运维领域,最主要的几个工作职责:

  1. 代码发布和交付(delivery),做好最后一公里的价值交付;

  2. 提升架构的可伸缩性(scalability)并付诸实施;

  3. 保障系统的稳定性(reliability)并不断改善;

  4. 在满足前三项目标的同时,不断优化并降低系统的运行成本(finops);


如果你发现自己的工作,并不是围绕着以上范畴展开,那么有两种可能,你不是运维或者你的工作超纲了!


明确了工作范畴,说大点就是明确了运维的使命之后,设定目标就相对容易些了,比如:

  1. 针对代码发布和交付,可以简单的用发布次数来度量;

  2. 针对系统的伸缩性,可以用扩容的时效性来度量;

  3. 针对稳定性,我们可以通过观察核心功能的不可用时长来度量;

  4. 针对系统运行成本,我们可以计算到每完成一笔核心交易所花费的资源成本和人力成本来表示和追踪;

关于如何体现运维的价值:

首先我们运维人要转变的是态度和立场:坚定和业务站在一起,争取共背业务目标。


我举个例子,HR 部门,也是属于公司内部后台的不能再后台的部门了,但是我所接触过的优秀的 hr 中,不管是 recruiter、还是 hrbp,从来都是把自己当作业务部门的一份子,把业务部门的目标当作自己的目标。当立场一致,大家都是自己人的时候,价值就好说了。


其次,价值这个事情,永远都是和“成本投入”相对应的。你如果组建了一个很大的运维团队,人力成本在公司很显眼,那么你就很容易成为老板眼中的“重点关注对象”,也会受到业务方更苛刻的挑战,正所谓,楚人无罪怀璧其罪:) 客观上来讲,运维团队的资源投入,一定是要和业务收入相匹配的,过高过低都是不健康的,不利于团队发展的。所以,“运维的价值创造”最后会落到运维效率的竞争上来。


最后,关于价值,定量和定性的描述都得有。譬如和行业水平的定量对比,来自公司内业务部门满意度调查的定量数据。也要有比如对公司战略项目支撑中的“存在感”这些定性数据。

ChatGPT 这样的 AI 能力您觉得未来是否有可能解决运维行业的问题?

首先我们看看,ChatGPT 的核心优势是什么?ChatGPT,在知识的丰富度、自然语言理解能力(以及上下文理解)、内容生成能力方面,有着代际的革新。


然后,我们再分析下运维行业的核心问题是什么?

  • 是缺少领域知识吗?

  • 是交互效率低吗?

  • 是内容输出难吗?


以上都不是,运维行业所处理的问题,本质上还是一个系统性的工程问题,是为了解决 IT 系统价值快速交付的问题、解决伸缩性的问题、解决稳定性的问题、是不断提高系统运行维护性价比的问题。


目前来看,云计算、微服务对于运维行业的改变来的要更实质性一些。ChatGPT 能有效改善运维行业知识沉淀的问题,或许会很快代替一些初级的运维架构师岗位。

工具选型这块,到底是自研,还是使用开源,还是使用商业产品,是如何抉择的?

这个问题没有绝对的答案,从我个人的从业经验来看,大概有以下几种情况:

自研的好处:

  • 心理上的自主可控感会更强一些;

  • 短中期维度来看,对于团队的发展空间会更有利;

  • 能根据自己的实际情况进行有针对性的、灵活的设计;

自研的弊端:

  • 时间成本很高,会造成较长一段时间拖后腿的情况,给业务的发展带来一定的影响;

  • 人力成本高,以北京为例,要招聘一位相对资深的工程师,每年的薪资大概在 50 万,如果要自研相关运维工具到成熟,投入两位工程师还是需要的;

  • 受限于研发人员的认知,自研容易和行业最佳实践脱钩,长期会造成内部工具落后于时代。

开源和开源二次开发:

好处是能很快见效,投入生产。坏处有三:

  • 开源工具一般注重灵活性,功能上也比较聚焦,在产品化和用户体验上通常比较欠缺,拿来快速使用存在体验方面的问题;

  • 写代码的朋友大家都有个体会,完全读懂和理解别人的代码和自己开发一套,难度其实是相当的,所以开源项目投入到生产环境,也是要投入足够的人力和时间去掌握的;

  • 大多数针对开源项目的二次开发,会导致和社区主干脱钩,导致无法顺利升级到后续的最新版本,享受不到开源项目真正的红利。

使用商业产品和解决方案:

优势:

  • 时间成本优势明显,借助商业产品能够快速敏捷的支持业务的发展需要,首先做到不拖后腿!

  • 原则上来讲,商业化产品的成本相比自研会有数倍的降低。这个成本差距是由商业模式决定的。商业产品能盈利的根本原因就是产品研发成本(加上销售成本)随着客户数量的增加而摊薄,否则这个公司没有存在的意义和可能;

  • 商业产品的核心竞争力包括领域 know-how、极致的产品体验、良好的技术支持和服务共同构成的,这通常意味着采用商业产品的技术团队会在公司业务方取得更好的口碑。


不足:

  • 国内 tob 领域起步较晚,目前阻碍客户采用商业化产品最大的问题是缺少极致好用的产品,以及价格优势还不明显;

  • 很多甲方客户技术历史包袱较重,个性化方案多,商业化产品往往很难做到完全匹配,导致客户不得不硬着头皮选择自研;

业内有观点认为云计算和 Kubernetes 这样的基础设施的崛起会让运维岗位逐渐消亡,您是怎么看待这样的观点呢?

诚然,云计算、K8s 的出现,核心是为了改进“运维”这个行业,对运维行业的工作方式发生了重大影响。比如:

  • 以前的 clickops 逐步过渡到 IaC

  • 传统监控升级为更全面的可观测性体系

  • release 也从大版本定期发布变成了更敏捷的持续集成

  • 老中医式的开源软件维护模式,变成了对应的云服务的正确选型和使用

  • 扛机器上架的体力活变成了简单的控制台分分钟开通

  • 手敲命令配置网络路由的专家工作转变成云服务的各个网络产品的组合搭配

  • 从物理机混部提升利用率转变为采用微服务、云原生架构成本天然下降


我们看到,运维工作的内涵并没有变,工作的价值也并没有变弱,只是运维要掌握的技能树在升级。运维人继续保持危机感、保持主动求变精神、立足服务好业务,就能永立潮头,处处柳暗花明。

可选的监控工具有很多,用户选择贵司的 Flashcat 平台,理由是什么?

的确,开源的、商业化的监控平台有很多,我之前也写过一篇博客:《二十年里12个开源监控工具大对比》,大家可以参考。


回到为什么选择 Flashcat 平台,需要从监控系统的发展趋势以及 Flashcat 平台的特点说起。监控系统的发展趋势,可以参考我之前的博客文章 《云原生监控的十大特点和趋势》。而 Flashcat 平台,正是面向这些趋势而生的针对性的解决方案:

  • Flashcat 面向更广泛多元的用户群:从面向运维工程师群体到面向全体研发、运营、CTO/CIO,Flashcat 让监控分析、信息拉齐如此简单;

  • Flashcat 与业务指标密切联动:当业务受损时,Flashcat 总能第一时间发现,并和 IT 系统深入联动,辅助技术团队快速展开调查;

  • 云原生、混合云统一监控:无论采用什么样的 IT 架构,您只需要一套 Flashcat 平台;

公众号推荐:

跳进 AI 的奇妙世界,一起探索未来工作的新风貌!想要深入了解 AI 如何成为产业创新的新引擎?好奇哪些城市正成为 AI 人才的新磁场?《中国生成式 AI 开发者洞察 2024》由 InfoQ 研究中心精心打造,为你深度解锁生成式 AI 领域的最新开发者动态。无论你是资深研发者,还是对生成式 AI 充满好奇的新手,这份报告都是你不可错过的知识宝典。欢迎大家扫码关注「AI前线」公众号,回复「开发者洞察」领取。

2023-03-11 13:486943

评论

发布
暂无评论
发现更多内容

WorkPlus:企业级私有化即时通讯软件

WorkPlus

考古:IT架构演进之IOE架构

乐只

系统架构 基础架构 IOE架构

在单交换机局域网中,不同网段的主机通信探秘🌐

GousterCloud

IP Linux Kenel

Doris 与 ClickHouse深度对比和选型建议

智慧源点

Clickhouse Doris

程序员晚枫|2024年3月总结,人生中第一次「车祸」

程序员晚枫

程序员 总结 自媒体

TiDB MVCC 版本堆积相关原理及排查手段

PingCAP

数据库 MVCC TiDB

为何一个网卡需要配置多个IP地址?🌐

GousterCloud

Linux Kenel 网卡 多网卡

Flink 文章

Joseph295

vim替换命令 “:s“

百度搜索:蓝易云

vim 云计算 Linux 运维 云服务器

一读就懂!B端响应式设计的新手扫盲

执于业务

夯实智慧新能源数据底座,TiDB Serverless 在 Sandisolar+ 的应用实践

PingCAP

数据库 TiDB

开源软件更安全吗?

冯骐

深度思考 开源 架构 开发者 安全

通过Golang获取公网IP地址

GousterCloud

#go 公网ip

“业务架构”

执于业务

Linux网卡与公网IP地址:一个不可随意配置的世界🌐

GousterCloud

IP Linux Kenel

月活超 1.1 亿,用户超 4 亿,你也在用的「知乎」是如何在超大规模 TiDB 集群上玩转多云多活的?来听听知乎代晓磊的答案!

PingCAP

数据库 TiDB

Oracle drop删除表如何恢复

百度搜索:蓝易云

oracle 云计算 Linux 运维 云服务器

Tortoise Git(乌龟git)常用命令总结

百度搜索:蓝易云

git Linux 运维 云服务器 Tortoisegit

WorkPlus Meet视频会议:打破时空障碍,助力企业安全高效协作

WorkPlus

PIRF393

EchoZhou

English

Linux网卡IP地址配置错误的影响🐧🔧

GousterCloud

IP Linux Kenel

如何应对复杂任务

Bruce Talk

敏捷开发 TDD Agile

Weblogic下启用Gzip压缩

百度搜索:蓝易云

Linux 运维 云服务器 weblogic gzip

C语言关于&与&&运算符

百度搜索:蓝易云

云计算 Linux 运维 C语言 云服务器

阿里巴巴中国站按图搜索1688商品(拍立淘) API:如何通过图片快速获取商品的标题、价格、图片、链接,提高了更加智能化、个性化的商品搜索体验

技术冰糖葫芦

api 网关 API 文档 API 类型

小红书笔记详情API接口:高效获取与分析内容数据的利器

技术冰糖葫芦

api 网关 API 文档 API 类型

WorkPlus AI助理 | 提供企业AI私有化部署解决方案

WorkPlus

探索Linux的挂载操作🌈

GousterCloud

Linux Kenel 磁盘挂载

金融企业区域集中库的设计构想和测试验证

PingCAP

数据库 TiDB

唐刘:关于产品质量的思考 - 如何评估质量

PingCAP

数据库 分布式 TiDB 产品质量

TiDB 慢查询日志分析

PingCAP

数据库 日志分析 TiDB 慢查询

快猫来炜:如何端好运维的饭碗_语言 & 开发_来炜_InfoQ精选文章