运维建设之运营思考

导读

本文将断续、松散的记录,楼主在运维管理和工作实施中的一些思考。


运维

2021.12.01 分工聚集依赖什么条件

圈里前辈安利一篇文章,文章的核心论点是”IT部门是否会被拆分到业务团队”,前辈的观点是”IT部门的职能会聚集到特定SaaS厂商”。

从经济发展的历史看,分工细化、专业化是一个趋势,”IT部门是否会被拆分到业务团队”的观点不慎靠谱。部分前辈祭出了”业务为王”的大旗,窃以为最多是正确的废话、甚至是混淆概念的说法;<国富论>讲,个人从私利的角度出发、最终能促进社会的整体进度,但很少上来就讲"为了社会的整体进度"的。

从经济发展的历史看,分工会逐渐聚集到少数寡头,这个结论成立的前提是: 产品或服务足够的简单标准化、需求足够平或有第三者负责抹平。”IT部门的职能会聚集到特定SaaS厂商”,依赖SaaS产品的足够标准,依赖IT需求高度标准化,IT个性化需求可能很难被优雅满足、此时就需要一个薄薄的IT部门来抹平。

最近圈里突然有太多的SaaS/PaaS热捧。对创业者来说,炒热一个方向、把自己放到头部固然没错;但也请留下口德,忽略现实、一味鼓吹会带骗很多后来人。

2021.11.30 向后兼容

昨天讨论RocketMQ管理平台设计,要求兼容老版本的产品特征,顺便整理了下”向前兼容”、”向后兼容”的概念。

  • 向后兼容,是新版对旧版的兼容,对应的英文是 backward compatibility 或 downward compatibility
  • 向前兼容,是旧版对新版的兼容,对应的英文是 forward compatibility 或 upward compatibility

我们一般会认为向前兼容是向之前的版本兼容,这个理解其实是错误的。

细细分析,类似前后这样的方向词汇,是以人个体为参照系的、有一定的主观性。汉语中,”向前看、这之前、前人、后人”的同字逆反表意,加重了混淆,导致: 以个人主观为参照系、解读出的含义,跟时间参照系得出的结论完全相反。同样的现象,还发生在对”左右”上。

2021.11.27 面向过程和面向终态

这两年一直认为,命令式是面向过程、声明式是面向终态,自己的这个理解不到位。

命令式、声明式的目标都是达成特定状态。命令式关注的是「操作结束后的瞬间、系统达成特定状态,之后的状态就不再关注了」。声明式则强调「通过自动纠偏、将系统长期维持在特定状态」。

面向过程这一描述,容易让人理解成为面向一个个的原子操作、而非执行结果,面向过程的定义没有描述实际情况、容易误导读者产生偏见。面向瞬态,可能是一个更合理的描述,至少看到这个定义,就能很好的判断”在什么场景下更适合用面向终态的方法解决问题”。

声明式词汇火热,我自己几乎把它等价成了面向终态,这也是不对的。声明式只是面向终态的一种实现,类K8S的Code编排方式也只是一种操作界面(被少数人神化了);运维领域已有的自动纠错脚本、自动预案平台、自动化工作流,也都是面向终态的实现,而且是很人文的操作界面。

2021.11.26 IaaS基础设施管理能力建设的延伸

适配API的多云管理更像是命令式,IaC则更接近声明式,两种建设思路均有适用的场景。具体分析下,

  • 命令式的目标是 达成瞬时结果 ,要求在操作结束时系统达成特定状态
    • 往往借助工作流,整合原子操作,实现复杂的业务逻辑,短平快
    • 建设顺序上,一般先有原子操作、后有工作流,原子操作维护人、工作流创建者可以松耦合,技术和组织结构相对松散
  • 声明式的目标是 维持特定状态 ,要求系统每时每刻都保持特定状态
    • 需要强大的中台引擎、实时的观察能力,实现复杂的业务效果,前期投入大
    • 建设路径上,一般是先有业务模型、然后做原子实现,技术和组织结构上更容易紧密结合
  • 运维的建设目标是「让IT服务系统长期处于最佳状态」,更强调状态的维持
    • 声明式需要前期大量投入,搞好中台,然后收获一个幸福的状态;命令式则需要在瞬间结果达成后,投入额外努力、来维持状态,且IT系统规模越大需要的投入越多,熵增效应显著

从上述分析看,命令式适合短平快、短期达成运维底线,声明式则适合长期建设、维持高性价比的运维终态

2021.11.24 平台建设的可选路径

昨天和两位SaaS老兵互撕,对平台的建设路径有了量化认识,包括使用开源、外采PaaS/SaaS、自建。如下:

page.png

不同国度、不同公司、不同阶段、不同领域,功能、体验、数据、成本的权重会有所变化,开源、外采、自建的得分也不尽相同,按需调整。

2021.11.12 流程容易虎头蛇尾

在流程建设过程中,经常出现一些蛇尾现象,如没做验收、没做发布。

针对这个问题、我们约定:新建的流程,其完成标志为完成一次团队内部分享。这样,既补全了验收动作、也增加了发布环节。

2021.10.31 再谈AIOps方向问题

在ROI近似的情况下:

  • 自建运维团队的公司,受限于本公司的体量,其AIOps「产出效果」不会持续增大,因此对AIOps的投入也无法长期维持;
  • 只有把整个运维领域当做目标市场,AIOps的产出效果才有可能被持续放大,对AIOps的投入才有可能长期维持。

说白了,AIOps的投入要求非常高,不是每个公司都能随便玩转的。大胆的预测下:AIOps这门生意会逐步集中到少数专业的、头部的AIOps服务提供商,AIOps将以SaaS化的方式长期存在、小打小闹的公司内部自建必将势微。

2021.10.09 AIOps是个伪方向

AI能力落地,需要多方面的条件,如业务的ROI、领域深度、场景精度等等。Ops本身是综合学科,核心场景偏重多、而不偏重精,能省钱但很难赚大钱,这跟AI的要求从本质上相悖。

窃以为,把AI做为运维领域的方向是有问题的,AIOps的概念被过度炒作了,甚至带偏了整个中国的运维领域。当然,能把AI做到ROI转正的SaaS提供商倒是可以AIOps为方向,但这仅限于领域内的少部分公司。

2021.09.30 运维流程的优化方式

运维流程的优化方式,可以从提升流程效率(效率)、加强流程管控力度(质量)、改善流程完整性(功能完整性)和流程可视化(功能易用性) 这四个角度进行。

  • 提升流程效率。缩短流程、减少人工、或加强人的能力,具体手段包括:缩减流程,流程自动化,提供流程决策所需的辅助工具(如根因定位),历史流程回溯复盘找到瓶颈点,等
  • 加强流程管控力度。事前把关(准入),事后运营(复盘)
  • 改善流程完整性。横向打通组织协作,纵向串联场景工具,兼顾商务、财务、运营等环节
  • 流程可视化。流程可视化,促进企业运维活动透明、信息共享,提升效率与体验;进一步就是度量

特别的,流程的运营,需要基于量化指标持续反馈、螺旋式进化。

2021.09.30 集约化是IT运维的目标

互联网IT运维,从手工运维,逐步发展出了标准化、自动化、运维和研发融合的DevOps等阶段。

对应的,运维管理也逐渐实现了集约化,包括运维团队集中化、设施集中化、数据集中化、平台一体化;管理平台的进化,是从最初的文档、脚本,发展到烟囱式、服务目录,再到场景闭环。

在当前的技术、组织、人文条件下,集约化是企业降本增效的必然选择。

2021.09.29 SaaS的经济本质

SaaS经济的本质是长尾市场的边际成本递减、边际收益递增的过程,更直白理解就是数字化的分期付款。对应的,SaaS产业的根本性问题是如何提高复购和续费率。

数字化的转型的本质是赋予业务以数据,而用户体验则是赋予数据以人性。洞察数据,赢得市场,洞悉人性,赢得一切。

参考:原文

2021.08.10 运维面

在微服务生命周期管理中,运维人员需要符合运维视角的运维面、即运维管理平台。

微服务架构中,一般会抽象出控制面(control plane)、数据面(data plane),方便架构管理。今天,听头条Mesh分享,明确提出了运维面(op plane),眼前一亮。

之前,总是感觉架构提供的管理平台非常难用,不符合运维习惯,但找不到具体原因。现在回想起来,架构视角的管理平台更多的是控制面、是架构能力的延伸,运维人员需要符合运维视角的运维面、即运维管理平台。

2021.05.17 AIOps的能力模型

AIOps能力体系,由运维数仓、AI框架和平台、运维场景等组成。其中,运维数仓需要融合领域,AI框架和平台投入产出比较低、小公司玩不转。

2020.11.25 关于AIOps的定义

软件的一些”算法逻辑”不代表真正的AI;AI的关键点在于: 自动从数据学习中总结规律,并利用规律给予决策建议(结合当前的环境)。

2020.11.17 代偿效应

结论:警惕代偿效应,警惕临时变长期。

再次被安全,再次SYS应急强上,不专业的人补位专业岗位,像极了医学上的代偿效应。什么是代偿效应,就是它不是你本身的目标,它是一个临时性的、应急性的、替代性的解决方案。举一个来自逻辑思维的例子、来证明它的危害:

很多慢性病病人,在早期的时候没有任何症状,看上去非常健康,自我感觉也良好。但是一旦出现症状,一查,就已经是中晚期了。这些病人就很奇怪啊,我明明一直好好的,怎么突然就病得这么重了?很多情况下,这就是代偿导致的。比如说胃癌。现代医学已经发现,胃癌和一种细菌有很大的关系,这种细菌叫做幽门螺旋杆菌。这种细菌一旦感染了胃部,就会持续攻击胃部的细胞,导致胃部细胞的死亡,引起胃炎,最严重的就是胃癌。那最治本的解决方案是啥?当然是消灭这些幽门螺旋杆菌。但是如果我们身体自带的免疫系统做不到,它就会启动一个替代方案,就是让深层的胃部干细胞加速分裂,赶紧补充死亡的细胞。这是啥?这就是代偿啊。这是一个临时性的、替代性的解决方案。那在我们人体的感觉中呢?胃的功能正常进行,啥感觉没有。但是,在你没感觉的同时,这场细菌和胃部细胞的战争其实是越打越激烈的。最后,当人开始有感觉的时候,说明就是代偿功能已经补不上细菌造成的损伤了,这场战争等发现的时候,就真的危险了。

完整文章,参见这里

2020.08.14 大规范小规范

规范有大小。大规范一般画出一个轮廓,能给出指导意义;具体落地则需要SRE的个人来执行(小规范)。 SRE个体习惯有差异,对小规范认知不一致,最后可能伤害到大规范的落地效果。这就像开发团队的代码风格治理一样,在小规范实施时,要有机制、拉平SRE的习惯认知。

2020.08.01 运维产出的思考

运维工作往往融合了 “技术+事务” 两个特色。事务性工作产出制度流程范式,使新人可以按图索骥、并以叠加式改进。技术性工作产出平台设计,以平台的方式沉淀运维能力(最佳实践)。

2020.07.23 做稳定性规划的一些感受

之前一般按照故障处理模型,来做稳定性规划。今年尝试从”对象+方向”双维度来做,效果还不错。一些小的感受如下,

  • 预案属于强业务场景,适合按场景闭环、不适合作为一个专项来做
  • 容量场景化较弱,适合横向展开。这根涉及容量的场景比较少有关

2020.04.15 工具是最好的协作者

工具是运维最佳实践的有效载体,最终都能进化为用户友好的形态。 从这个意义上讲,工具可以协助降低对从业人员的服务心态要求。在工具达到一定能力之前,所谓的服务心态很难维系。

2020.04.01 传统Ops和SRE主要区别

Ops倾向于被动执行,而SRE倾向于主动思考

2020.03.25 关于分阶段交付

人力有限时,大项目往往要分阶段交付,每个阶段交付1+个相对独立的产品功能。

Dev同学可能对分阶段认识有误区,可能会站在技术或代码开发的角度来分阶段,导致无法持续交付产品功能。这一点需要关注。

2020.03.15 一线同事能力较差时,如何保证结果质量

由于历史原因,团队会留下了一些能力较差的一线同事,且主动/被动进化的效果不理想。为了利用这一部分人力,同时达成高质量的结果,团队采用了 架构师带队、一线人员执行、团队集体验收 的合作模式。

架构师是负责人、责任人,协助梳理目标、分解里程碑、制定验收标准、定期检查。一线人员拿到的是一个可执行、能度量的任务,不需要太多思考就能准确实施。架构师定期组织一线员工检查中间状态,整体完成后团队成员一起检查结果、确保效果高质量达成。

关键点:推动被动老员工的个人提升有难度时,可以选择用合理的分工来充分利用人力。


管理

2021.09.29 能力和地位要匹配

《周易·系辞·下》有云:「德薄而位尊,智小而谋大,力小而任重,鲜不及矣」。地位过低、过高,都会有问题。

2021.09.23 隔级指导不可取

DEV方向人员流失严重,我亲自担任了一名校招新人的导师。辅导期间,很多我认为是必备的常识、技能,新人都不具备,部分错误在我看来甚至很低级。几次下来,辅导过程就比较严厉了,新人承压。回想起来,这已是第二例Case。

问题出在「隔级指导」上。导师和新人之间,如果能力代差大于1代,对导师来说就会比较煎熬;如果遇到我一样急脾气的导师,新人就会承压,辅导结果也不会太好。

隔级指导,本质还是团队梯度建设有问题。

2021.07.15 团队需要适度的讲人情

团队内部需要讲究人情,需要人文温度。针对团队老人,需要给与足够的宽容、足够的成长帮助和耐心。借用《潜伏》吴站长的两句话,来表达下我的团队人情观:

1、没有人情的政治是短命的。人情无需分敌我,何况是一个团队内部!

2、不注重情分的人难堪大用。无情未必真豪杰,怜子如何不丈夫?心怀感恩,方能致远。

当然,人情观的底线是不能损害团队重大利益。毕竟,公司是盈利组织、不是慈善机构。

2021.06.16 价值驱动和目标驱动

团队需要定义清楚核心价值,然后由核心价值、推演出不同阶段的工作目标。价值是目标的筛选器,目标是价值的实现路径。

上述思考,来自上半年的惨痛教训。之前,不太重视团队价值的定义,觉着太虚、浪费时间。上半年,老板、老板的老板建设预期高涨,容器改造、多云容灾、网络基建同时上马,建设目标不断提升;OP在稳定性上的投入被严重挤压,最终酿成2起重大故障。对应的,绩效评估也暗淡收场,虽然建设目标达成的不错。这时,我才突然意识到:稳定性这一核心价值没有达成,其它所有的建设功劳都显得那么苍白无力。

经此一役,我深刻的体会到「明确定义团队核心价值」的重要性。团队价值是筛选器,它决定了团队要做什么、不做什么、重保什么、放弃什么,特别是资源有限的情况下

2021.04.22 对员工是有限责任

TL对团队成员是有限责任。如果一年还没培养起来就放弃吧,不管这人有什么优点;培养不起来,本身就是最大的问题。

我用半年的精力,把人从入门、培养到能做事,接下来一年半始终没能进步到极致。现在想想,他本身就有天花板,早点Fail、让他找到合适的位置更好。心慈,不一定是好事。

2021.03.02 高阶招聘

高阶招聘,需要同时做到:调度资源、掌握人脉。且人岗匹配。

2021.02.01 向上管理的职责

中层管理者的向上管理职责之一,在于:为更高层老板,争取决策的时间、资源、主动性。

2020.12.20 成果和贡献的平衡

年底打绩效时,发现某些成员的OKR得分远高于/低于日常感受。分析发现,得分过高的成员的OKR往往以”从0到1”的工作为主,得分过低的则以”从1到100”为主。

从0到1,一般是在填补某方面的空白,成果显著;从1到100或者从50到100,一般是在维持运转,默默贡献。现状中,大部分公司、团队、个人,重成果、轻贡献,OKR量化后这个问题更明显。久而久之,没人再愿意做从1到100的事情了,而这正是公司运转的主要投入方面。

如何平衡呢?

  • 在绩效结果打分环节,管理者有意识的平衡成果和贡献。我这里采用了”OKR打分为主、组长打分辅助验证”的方式,两种排名差异大的成员重点重新review
  • 在绩效目标制定环节,如何平衡成果、贡献的比例,也是需要关注的一件事。比如,从1到100的KR,如何考核其确实在进度

2020.12.10 价值来自关键链路节点

如何衡量个人的工作价值?拎出来看看,你是否 “在某个关键价值的必经节点”。

团队间的分工,底线也在于关键节点。

2020.07.19 领导团队的关键点

领导团队的关键点有:看方向,带人,做事。最近一年,在带人、做事方面都算过关,但在看方向上做的较差。 要么主动思考、要么被安排,方向大事容不得一丝懈怠。


个人

2021.07.18 生命的意义

当他回首往事的时候,他不会因为虚度年华而悔恨,也不会因为碌碌无为而羞耻;这样,在临死的时候,他就能够说:”我的整个生命和全部精力,都已经献给世界上最壮丽的事业 —— 为人类的解放而斗争” —— 摘自《钢铁是怎样炼成的》

今天北航故地重游,和两位老朋友走走老路,回首往昔、吹吹牛逼。大家都有了属于自己的精彩和遗憾,不无悲伤、也算完美。每个人都可以有自己的追求,我只愿:生命不止、奋斗不息!

2021.05.16 职业生涯的长期主义

做职业生涯的长期主义者。

除了明确职业目标外,增加生命长度、有效利用时间,也是两个关键指标。「增加生命长度」,感觉忽视了!

2021.04.22 个人成长的负面例子

隔壁的例子。被下属顶替了,不是因为下属太优秀,而是因为上级不再成长。他山之石,历历在目。

2021.04.17 人际资源的年代局限

人际资源,有明显的年代局限,一般是上下5年。对应的,个人职业高峰,最多也就维持10年。

跨1到2代、建立年轻化的工作联系,有利于打破上述局限。需要刻意为之。

2021.04.16 体系化总结和产出

工作可以很琐碎,但产出必须体系化。体系化,才有可能固化为知识、方法论。

体系化产出,依赖周期性总结。周期可以是天、周、月、季、半年、年,取决于工作环境。月度够用。

2021.03.01 刻意练习

体系化的成长,来自:1分培训、2分交流、7分刻意练习。刻意练习,就是带着理论做实战、边实战边吸收理论。

2020.11.30 警惕舒适区

今天面试了一位候选人。他有13年运维工具产品/架构相关的工作经历,本次工作希望转入SRE、以实践落地其工具创意。考察发现,该候选人没有完整的运维工具体系知识,相较13年的领域工龄着实可惜。

工具创意可能就是他的舒适区,13年时间沉浸其中,忽略了体系能力的建设。再加上知识更新不及时,就这样失去了竞争优势。想想自己,也是偏执于工具创意,甚至建立起了小范围的优势。后续一不小心,可能就掉在舒适区、走不出来了。

以此为鉴,警惕舒适区、加强定期反思。

2020.07.18 刻意练习不能丢

最近半年借口太忙,在刻意练习上投入的很少,导致能力体系进步较少。 回想一路走来,每次实质性突破都有刻意练习的影子。定个小计划,后续每周留2-5个小时做刻意练习,加班很关键。



Prev     Next