运维建设之日常思考

导读

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



技术

2022.08.23 模型归纳法

五段式归纳法「模型、指标、目标、路径、组织」,适合构建全新的场景模型,已经在成本优化场景中证实。

经典归纳法之「质量、效率、成本、安全」,试图以画框填空的方式、辅助横向查漏补缺,但并不适合纵向梳理。

生命周期归纳法,非常适合纵向梳理,待体系化产出。

2022.08.16 Fuck同环比

环比、同比用于描述统计数据的变化情况,两者经常因为 不同语境预设的统计周期 而混淆。

环比表示 本次统计周期与相连的上次统计周期 之间的比较,是两个完整统计周期之间的比较。比如2010年中国第一季度GDP为G101亿元,第二季度GDP为G102亿元,则第二季度GDP环比增长 (G102-G101)/G101,这里的统计周期是一个季度。

同比表示 某个统计片段本周期与上一周期 之间的比较,是两个统计片段之间的比较。比如2009年中国第一季度GDP为G91亿元,则2010年第一季度的GDP同比增长为 (G101-G91)/G91,这里的统计周期是一年、片段是一个季度。

类似 2010.10、2010.08这两个月的比较,中英文都没有对应的专有名字。之前,通常把这种情况叫做环比、因为这是两个以月为周期的比较,现在看有很大问题、因为两者并不相邻,称作”月度比”更合适(既不同也不环)。时代发展太快,语言演化偶尔都跟不上节奏了,何其幸哉、何其悲哉。

2022.08.11 滴滴闭门会的思考

今天参加了滴滴运维闭门会,记录当时的几个输入。这些输入,最后都应该被归纳到对应的主题。

  • 平台:可观测的瓶颈已经从平台能力、转移到数据标准化,归根结底还是标准化
  • 平台:放火平台目标是,构建风险可控、可重复执行的场景验证能力,验证内容主要是服务架构、运维管控的完备性
  • 平台:KubeVela本质是声明式的交付编排,支持研发、运维视角的关注点分离OAM

2022.07.21 尊重大势

公司技术项目的成功,除了组织给力、人才足够、技术具备等因素外,公司大势是第一要素。

比如,我司多云+云原生能够高质量落地,依赖高效的组织、经验丰富的人才、成熟的社区技术,但首先是「国家监管情况下的 业务增长骤减、存量还能维持」、这位技术升级提供了宝贵的时间窗。

回头想想,技术发明、人生际遇也都是如此。大势面前,所有其它因素都是技术性的。

2022.07.15 数字孪生的一些理解

数字孪生(Digital twin),本质是:把物理对象搬到数字空间分析,并用分析结果控制物理对象。关键点包括数据采样、数字建模、挖掘分析、控制执行等。如下图,

pict.png

和数字孪生相关的概念,还有 计算机辅助工程CAE(Computer Aided Engineering)。

2022.07.14 顺丰数据中台的启示

顺丰数据治理体系的理念,包括:一套治理体系、一个数据中台、N个应用。要践行这样的理念,首先需要管理层共识,支持推下去;其次,平台要足够简单透明,让用户愿意配合;最后,要有配套的数据运营,需要有一条准绳、确保标准规范得以落地,并让数据的价值得以数字化显现。

顺丰在实际业务场景落地时,最大的困难在于内部推动,需要管理层自上而下推动。因为,数据共享、多人协同、数据标准化都是需要跨组织拉通,并推动对现有的内容进行改造的。从结果看,顺丰的数据中台能够顺利推进,最大的因素是管理层下定决心、坚决落实。反观,技术能解决的问题都不算是大问题。

顺丰数据中台的建设过程,很像我司的多云建设。强权的组织结构、自上而下的推动方式、统一的治理方案、重视标准化运营,这些也是我司多云能够成功的关键点。

2022.06.30 认知代差会招致降维打击

认知代差,会让你错失自我革新机遇、逐渐变的落后,最终招致降维打击。

比如,大清朝自诩天朝上国、宗藩中心,没有意识到世界新形势,招致帝国列强的轮番撕咬、险些亡族灭种;之后虽有变法维新、洋务运动,但都没有触及精神内核;直到吸收转化了新民主义、共产主义,中华民族才得以重返世界之林。

再比如,我大运维团队,前半程固守老旧经验、错失了云原生的先机,差一点被打到魂飞魄散;之后我们努力补课、自我革新、吸收转化新理念,持续两年多、才实现了赶超。

认知不够、努力也白凑;能力的提升,首先要从认知开始。这是多么痛彻的领悟啊!

2022.06.24 标准化是批量管理的前提

技术对象的标准化,让运维批量管理成为可能。举个配置监控大盘的栗子,

之前,监控数据不标准、各业务乱打,配置大盘时只能填写完整的指标键值对。为了实现批量管理,很多公司会搞一个指标管理系统、人工维持打标分类(大数据BI平台的标配),然后再根据这个系统、生成监控指标配置、填回到监控系统 —— 在展示层做指标配管固然能解决问题,但处于链路末端的配管 不免重复建设、运营成本高,很容易走向裂变。

反观,服务治理完成后,大部分监控数据由网关、Mesh、框架、系统自动生成,而且受控于服务治理体系的中心配管;监控数据的指标名、服务管理标签高度统一,监控数据本身就能很好的自说明。运维也会做一个配管,在数据生产后、入库前补全上管理标签。此时,配置大盘就可以使用Repeat选项、批量生成,后期运营也几乎是零投入 —— 前置的中心配管+服务治理链路,最大程度的规范了数据生产,在源头上避免了数据裂变。

上面这个例子也说明,标准化的生成要在生命周期的起点,而不是中间、末端。

标准化是服务治理体系要承担的使命,构建在服务治理体系之上的工种、都将是受益者。题外话,监控产品的使用难点有可能不在产品本身、而在客户数据的标准化,监控SaaS厂商除了卖产品、可能也要同步兜售服务治的理解决方案。

2022.06.21 问题驱动从来就不是问题,机械的思考和行为方式才是问题

因为X,经常把「问题驱动」当做形而下的末流、并深以为耻;而真实的工作中,50%+的技术进步又来源于问题驱动,理念和实践有巨大差异。这是为什么呢?

实践是真实发生、持续验证的,大概率是没问题的,问题只能出在理念上。我们对「问题驱动」的理解,到底有什么不对呢?经常被一起提及的还有「规划驱动」,尝试通过几个维度来对比下(问题驱动 vs 规划驱动),

  • 灵感来源:当下遇到的问题 vs 当下遇到的问题 + 历史上总结的经验
  • 决策过程:简单粗暴的拍板 vs 深度思考、充分论证,伴随着认知提升
  • 对象范围:头疼医头脚疼医脚 vs 合理的时空延展
  • 解决方案:机械的修复,补丁之上打补丁 vs 全局性、前瞻性的解决方案 + 可迭代的实现路径

从这几个角度分析,问题驱动、规划驱动的灵感来源是相近的(经验也大多源于问题),主要差异在决策过程、对象范围。可以大胆假设下,问题驱动这四个字、最初只用于描述灵感来源,但在实践中逐渐被用于指代那些机械的思考和行为方式,「问题驱动」这个词被用烂了。

这样看,问题驱动从来就不是问题,机械的思考和行为方式才是问题。更高一级的目标驱动,也是以问题、需求为灵感来源的,是高水平认知在低纬度的投影,这个能力需要逐渐积累(梦想驱动也大多源自问题吧)。

2022.06.09 关于创造性工作的思考

①创新不是灵感突现,而是耐心地从失败中观察、改进(詹姆斯·戴森)。

今天听《发明》一书,是戴森公司创始人詹姆斯的自传,其中介绍了技术创新的方法。大体如下:

人们常常以为,发明的关键是灵感。戴森公司创始人詹姆斯认为这是一个误解,他以自己的经历告诉年轻人:发明更加看重的,不是灵感、而是一个人的耐力,看他能不能耐心地从失败中观察、改进。

绝大部分时候,创新不是灵感突现,而是耐心地从失败中观察、改进,是对专业的持续改进、是微创新的集腋成裘。我个人感受的创新路径是:「实践 -> 深度思考 -> 改进 -> 实践」,这个路径持续循环,其中 深度思考是创新发生的关键点。

②创造性工作要找准边界,在边界内做事情。

好的发明人要在时代的边界内做事情,好的工程师要在公司的边界内做事情,好的架构师要「在公司的边界内落地新技术」、而不是空谈误国。这些思考,来自「得到-硅谷来信2·谷歌方法论-计算机从简单到复杂」。精简信息如下:

巴贝奇(滑翔机之父)的悲剧在于他的想法太超前,以至于当时的工业基础无法满足他的设计要求(自带动力的飞机)。 从这个意义上讲,巴贝奇更多地是科学家,而不是工程师。我在《见识》一书中介绍了前苏联设计和制造“米格25”战斗机的成功经验,从那个案例中可以看出好的工程师是如何在边界之内做事情的。

③创造性工作有运气成分。

科学技术领域的成就,依赖时代赋予的大势;工程领域的成功,也要等到风云汇聚、各种条件都成熟,俗称运气成分。比如我们云原生架构团队,其成功的关键,既有自身经验和努力、也有运气成分,他们来我帮足够早、以至于云原生还没有在作业帮落地,他们来我帮也足够晚、以至于K8S社区和公有云都已经做好了准备。

上述思考,来自「得到-硅谷来信2·谷歌方法论-发明背后的逻辑」。精简信息如下:

成功的发明要等到风云汇聚,各种条件都成熟。莱特兄弟成功的关键,既有自身科学的方法和努力,也有运气成分:莱特兄弟出生得足够早,以至于飞机还没有被发明;他们出生得也足够晚,以至于凯利的理论和奥托的内燃机都已经为他们准备好了。

2022.04.22 微服务化治理的挑战

微服务是一种软件架构、组织方式,通过将大型的服务、拆解成独立组件,来解耦人员和应用的生命周期。

在云原生的大潮下,微服务架构在应用层全面达成,并且按照应用视角、完成了资源(容器技术)和组件(网关代理)的部分服务化。但我们也能看到,当前依然有很多对象,无法像服务端的应用一样、按功能拆分成微服务,也无法低成本的迁徙改造。比如:

  • 数据:数据库集群,大数据离线、实时服务,对象存储桶、共享文件存储
  • 组件:接入网关,服务化框架,服务域名,消息队列集群
  • 资源:网络地址、安全域,未容器化的虚机
  • 客户端:历史版本

在当前的技术发展阶段,微服务的组织方式有局限,无法用于管理数据、组件、资源、客户端等对象。这可以作为运维管理的技术边界。想要以微服务化的视角管理所有对象,就要找到合适的技术方案,避免人肉运维。

2022.04.15 重复造轮子是否合理?

重复造轮子是否合理,可以分几个维度看:

  • 以个人牟利为出发点的轮子,绝对不正确。资本家视角,但没啥毛病
  • 商务角度看,具备成本、安全考虑的轮子可以重复造,此时轮子不是关键点,轮子背后的价值是关键点
  • 技术角度难有结论,因为技术的产生环境有差异。技术是否先进的评价,容易陷入事后诸葛亮

pict.png

技术是否先进,有点”文无第一”的味道。

2021.12.29 架构选型的关键点

架构选型要做好长短期利益的权衡,很多时候要放弃短期最优解、采用次优解,来平衡短期和长期的利益。

架构选型要客观思考、避免个人偏执,尽量避免手里有锤子、一切问题都是砸钉子的事情发生。

具体的,

  • 做好长短期利益的权衡
    • 问题:架构选型时,一般会面对 1、短期的痛点,2、中期的瓶颈,3、长期的先进性。技术经常面临的问题是,长期容易被低估、短期又会被高估
    • 原因:究其原因,人类的天性就是容易看到眼前的问题和痛点,在思考问题时也会从眼前的问题着眼入手出发。这本身是无可厚非的,也是符合客观规律的。毕竟,「先活下来」永远是思考的第一要素。
    • 解法:但是对于资深的架构师来说,技术选型中短期的利益往往是会和中长期的收益存在着或多或少的矛盾和取舍。这就要求,有时候要放弃短期的最优解,采用次优解,来平衡短期和长期的利益
    • 评价:架构选型要兼顾短、中、长三期解决方案,给出合理的过渡方案,不考虑现状的rearch都是空谈
  • 客观思考、避免个人偏执
    • 问题:每一位架构师其实都有一些自己的偏好,有一些自己的执念。
    • 解法:从实际问题出发,避免个人的经历、偏好、执念对技术选型的影响。在做技术选型时,能时刻警醒自己,跳出来,从一个相对客观的角度,从问题域出发去评估整体选型,而不是从具体的手段、方法来看待问题,尽量避免手里有锤子,一切问题都是砸钉子的事情发生。
    • 举例:当然,这也是一个知易行难的事情。我个人的一个具体实践是,在做技术选型和设计时,即使未来是要自己去落地,也不会把自己代入未来的执行层面或者实施层面去思考细节。当然,如果设计和落地本身是分离的,就没这个烦恼了。但是,大多数时候架构师是没机会真正置身事外的做一个「顾问」的。

架构师的价值,不在于创新,而在于为公司选择一条稳妥的、合适的路,不求原创、但求合适。

2021.11.27 面向过程和面向终态的对比

面向过程、面向终态是两种自动化系统建设思路,两者本质区别是建设目标不同,目标差异也延伸到了交互形态、技术路径、运营成本、适用场景等多方面。大体如下:

  • 面向过程
    • 建设目标:操作结束后的瞬时、系统达成特定状态,不关注之后状态。面向过程又叫面向瞬态。
    • 交互形态:命令行、工作流、Terrafrom
    • 技术路径:使用工作流或人工、编排原子操作,实现复杂的业务逻辑;顺序上,先有原子、后有编排,原子、编排两拨人做,组织结构解耦
    • 运营成本:前期能复用经典工作流等能力、短平快,后期运营成本高(额外投入运营力量、维持状态,IT系统规模越大需要的投入越多,熵增效应显著)
    • 适用场景:机器购买、域名解析变更
  • 面向终态
    • 建设目标:通过自动纠偏等方式,将系统长期维持在特定状态
    • 交互形态:配置定义、K8S声明式
    • 技术路径:需要强大的解析引擎、控制器、实时观察能力,实现复杂的业务效果;顺序上,先有业务模型、后做原子能力,组织结构更紧密
    • 运营成本:前期建设难度高、投入大,后期运营集中在工具建设、可收敛
    • 适用场景:节点池宿主数量、K8S Pod个数、配置版本发布

两种建设思路不能代表技术优劣,如工作流经常用于面向过程、但也可以做成面向终态;技术只是实现目标的手段、并无高下之分。回到运维领域,运维建设目标既有瞬时交付、也有终态维持,两种思路都能用得上。

2021.05.16 云原生的简单认识

云原生是一套开放的基础设施建设标准。基本上,向下抽象IaaS、中间约定PaaS建设规范、对上呈现应用接口。

K8S是云原生标准的一套开源实现方案。K8S的理论基础脱胎于谷歌Borg,在IaaS资源抽象、PaaS托管规范方面做的不错,向上的应用接口还在进一步优化中。

K8S不等于云原生。符合标准的公有云、私有云、混合云方案,均可认为是云原生。

详情可以参考: 云原生之架构思考

2021.04.01 美团技术发展的跟跑策略

技术建设要比业务需求快一步、比业界先进慢一步,要在思考深度、技术体系性上做到业界最牛。

这是美团的跟跑策略,在技术方向的体现。略有参考价值。

2020.09.25 元数据运营的关键点

好的元数据运营体系,应该具备这些特征:强依赖、可复用、可校验、可收敛

  • 强依赖,至少被1个关键的管理路径依赖;
    • PS:如果被服务调用链路依赖,那非常不幸,因为元数据改动很慢、长期无法收敛
  • 可复用,能被2+个场景使用、实现价值扩展;
  • 可校验,在现有元数据体系中,能交叉互验数据的正确性,降低修复更新成本;
  • 可收敛,生成和维护成本可以逐渐降低,数据质量可以逐渐提升、最好是自动提升

强依赖、可复用、可校验,很大程度上都是在推动可收敛。是否有利于元数据的收敛,是判断一个运营方案好坏的重要指标。如,

  • CD审批,上线审批权限点是一个差方案、因为审批权限生成过程收敛成本高
  • 服务负责人审批是一个好方案,因为服务负责人是一个可以被精心维护的元数据

说的再激烈一点,元数据不收敛、罪一定在平台(的运营方案设计)。

元数据运营,应遵循如下分工:

  • 谁交付、谁生产。服务提供方主R功能交付,是元数据生产者;生产行为通常有交付平台实现
  • 谁生产、谁管理。服务提供方是元数据管理者,有责任运营好元数据质量,『管生也要管养』
  • 消费者不承担管理职责。合法的消费者有权享受符合SLO的元数据、而不需要付出管理成本


运维

2022.09.08 谷歌SRE视角的应用生命周期

谷歌把服务生命周期划分为五个阶段。它认为,从Idea确定那一刻应用就诞生了,然后进行架构设计,接着进行开发,再灰度/全量放量,最后到该服务弃用,终结生命。如下图。

pict.png

上述内容引用自《SRE运维思考与实践》一文,作者是作业帮SRE负责人邓瑞龙。

2022.07.07 如何解读「运维的最终目的是服务业务」

「运维的最终目的是服务业务」,这个观点很模糊,看似是在表达目标、其实还在暗示方式。有必要好好分析下:

首先,任何技术岗位的存在价值,都是为了达成业务目标、为公司开源节流,运维岗位亦是如此。这是政治正确,不存在任何异议。

其次,服务业务的方式有很多种。你可以融入业务前线、成为业务的一分子(Tobe),可以紧贴业务、提供保姆式护航(Sidecar),也可以强化分工、用专业能力服务好业务(SLO)。从人类社会的发展路径看,专业分工的方式可能会走得更远。

So,目标、方式要分开看,没有谁是政治不正确,只是采取的方式不同、而已。

2022.07.02 如何看待监控(monitoring)和可观测(observability)

可观测是一个服务治理的概念,鼓励应用以标准方式、充分暴露自己的状态,以便于从外部做应用诊断,这个过程很像数字孪生中的对象数字化。我所理解的监控,是构建在状态数据之上的、全局视角的产品功能,属于应用诊断的范畴。So,监控、可观测不是同一个维度的东西,监控是base在可观测之上的。

以下是之前的分析,错把可观测当做应用诊断的产品功能来对待了,不过也有参考意义、保留下来。

  • 业务场景:监控用于稳定性管理,典型功能是故障报警、全局定位Scope;可观测用于质量管理,典型功能是链路分析、应用分析Apm,从外部的数据特征、推断应用的内部状态(数字孪生)
  • 目标用户:监控对运维、研发TL等有全局视角的工种比较友好,可观测对研发RD更友好
  • 平台功能:监控以Metric为基础,主要功能是故障报警、时序报表;可观测覆盖了Metric指标,同时还囊括了Logging、Tracing、Event等APM能力。监控是可观测的子集
  • 技术手段:监控专注于时序数据分析;可观测更强调关系数据挖掘,更像是应用领域的实时大数据BI

2022.01.09 代码是工具知识的最佳载体

最近看HashiCorp联创采访,其对工具输入的理解挺有意思: Knowledge should be represented as Code,典型代表就是IaC。

工具的输入方式,先后有Env、Config、命令行、API接口、UI、Code等形式。Code方式在「知识沉淀+传播」上有优势,受到了创投界追捧。

2022.01.09 开源的价值在于形成事实标准

利用开源、形成事实标准,是企业最牢固的隐形护城河。开源社区的用户,都是你潜在的客户,他们有付费需求时会优先考虑到你。一旦你成为了事实标准,社区用户即使没有付费也是你的护城河,因为他们一旦有付费的需要,你的产品肯定是在优先考虑位置上。这极大挤压竞争对手的空间,这里的竞争对手甚至包括将自研产品开源出来的科技大厂 —— 科技大厂不是目标付费客户,但是他们内部使用开源产品替代自研产品,实在太普遍了。

工具类产品比拼的不是单纯的性能,更是工具背后的、代表新生产方式的方法论。把最佳实践抽象成方法论,才是真正的企业护城河。

以上内容,引用自「HashiCorp联创采访纪要」。

2022.01.03 中国的运维领域缺少体系产出

中国的互联网运维领域为什么缺少体系产出,如ITIL、Devops、K8S等?相比而言,中国运维领域的分工偏重运营,这带来了很多问题。如:

  • 资源投入不足,国内大环境重业务、轻运营,运维拿不到足够的优质资源、做长做深。这是中国互联网基础设施的通病,不限于运维领域
  • 专业深度不够,受困于运营的定位,运维工作者缺少软件工程思维、不知道如何深挖,虽然运维的场景足够广。运维只能附庸业务、寻求安逸,价值越做越薄,大部分老兵会在10年内转行,这又加剧了人才不足
  • 技术革新滞后,运营属性决定了运维成为应用学科、而不是基础学科(基础设施方向),运维处在技术的最外延、很难自我革新,历次技术革命都依赖外部输入

运维领域想要体系产出,可能要分出一部分人:在充分了解运维场景之后,吸收软件工程知识、养成基础学科意识,在一个更高的维度完成对运维工作的系统化抽象。这部分人就是运维架构or运维中台。康威定律再次发挥了它的指导意义。

2021.12.29 中国不需要照搬AWS模式

今天听到一个有意思的说法,个人比较认同,如下:

“AWS之所以成为现在的AWS,核心是老美的甲方有一帮足够短视且极度利己的职业经理人,以及他们所处的商业环境。 我个人认为中国不需要AWS,中国需要的是稳定且可靠的基础服务,或许它是分散的、或许它的社会效率不算最高,除非是打算出海赚钱、和AWS抢市场”

公有云虽然被认为是基础设施,但基础设施不单纯是技术、更多的是业务场景,基础设施本身就是业务场景。技术可以通用,业务场景可以遵循中国特色,窃以为「中国不需要照搬AWS」。

2021.12.01 IT职能是否会聚集到头部SaaS厂商

圈里前辈安利一篇文章,核心观点是 “IT部门的职能会聚集到特定SaaS厂商”。

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

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

20220711按:上述观点之争,就是「甲方追求实用、创投追求先进」的一个典型,两者是站在不同的时代、思考同一个问题。放眼将来,大部分IT职能会聚集到头部SaaS厂商,IT服务会变的高度标准化、个性化会被模块化组件抹平,IT部门也将随之弱化

2021.11.30 向后兼容是新版对旧版的兼容

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

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

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

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

2021.11.24 平台建设的可选路径

昨天和两位SaaS老兵互撕,对平台的建设路径有了量化认识。平台建设可以采用开源+二开、外采、自建三种途径,对比如下:

page.png

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

2021.10.31 AIOps是ToB生意、不适合自建

AIOps技术体系,由运维数仓、AI框架、AI平台、运维场景组成,要求具备理论基础、人才密度、场景精度、业务深度等。需要注意的是,软件的一些”算法逻辑”不代表真正的AI,AI的关键点在于:自动从数据学习中总结规律、并利用规律给予决策建议。

AIOps不适合自建。前期要求高投入、后续无法持续产出,ROI太低。AIOps能力体系前期需要集中的高投入;即使解决了前期的高投入问题,受限于公司体量、自建AIOps的产出效果很快就会遇到天花板、不会持续增大。加之,AIOps落地的产品太少、未兑现AI效果,人心早已疲软。

AIOps更适合ToB。在持续高投入的要求下,只有把整个运维领域当做市场、有足够的收入来源,AIOps才能ROI转正,才有可能持续投入、持续产出(资本密集型)。AIOps这门生意逐步集中到少数SaaS厂商,大部分公司从自建、改为外采,这可能是最终形态。

之前的几年,AIOps的概念被过度炒作,大大小小的公司都尝试自建、结果碰了一鼻子灰,甚至整个中国运维领域都被带偏了。带节奏也要负责任!

2021.09.30 运维流程的优化方式(思考尚未成熟)

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

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

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

2021.09.30 集约化是IT运维的最佳组织结构

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

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

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

20220712按:组织、资源、数据的集约化,为运维管理做好了组织准备。之后,需要将运维能力服务化OPaS,运维通过平台、和上下游业务相互依赖,这是技术目标。

2021.09.29 SaaS和企业数字化转型的几个观点

SaaS经济的本质是市场角度的「长尾边际效益递增」、金融角度的「数字化分期付款」。对应的,SaaS产业的根本性问题是如何提高复购、续费率。

SaaS产业过去和现在的商业本质是资本和产品,未来的商业本质必将是用户体验。SaaS厂商要做到极致的用户体验。用户体验的终极形态应该是自私的究极体现——我感受不到你的存在,但我需要的时候,你的服务总是那么恰到好处,深得我心。

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

参考:原文

2021.08.10 运维面

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

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

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

20210713按:运维面(ToM)沉淀了适量流程规范,是全局视角的操作习惯;再往上还有用户面(ToC),结合了严格流程规范,是适合RD的应用视角。

2020.11.17 警惕工作中的代偿效应

警惕工作中的代偿效应,避免补位现象长期持续。

被安全后SYS再次应急强上,不专业的人补位专业岗位,像极了医学上的代偿效应。什么是代偿效应?代偿效应指的是用临时方案、替代弥补掩盖原方案的不足,短期能达成预定效果、长期会留下永久伤害。举一个例子、来证明它的危害:

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

完整文章,参见这里

2020.08.14 规范落地依赖中心权威

规范有大小。大规范一般画出一个轮廓,能给出指导意义;具体落地则需要SRE的个人来执行(小规范)。

SRE个体习惯有差异,对小规范认知不一致,最后可能伤害到大规范的落地效果。这就像开发团队的代码风格治理一样,在小规范实施时,要有机制、拉平SRE的习惯认知(事实证明 个体自觉不靠谱)。

20220713按:规范落地 要依赖强大的中心权威,寄希望于个体自觉是非常不靠谱的。对于外延规范,中心权威能被平台替代;对于元数据,中心权威不可替代。

2020.04.15 平台是最好的协作者

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

2019.03.22 业务运维的宿命思考

业务运维的具体工作,通常涉及两个领域:运维、业务。

业务运维的组织形式,一般有两种选择:统一的大业务运维团队、业务运维打散到业务线,前者如谷歌,后者如2018年的阿里集团。也存在第三种过渡性态:保留最小业务运维团队、同时业务线出人承担大部分运维工作,如2018年的滴滴。

不同的组织形式,是在运维专业性和业务人效上做折中。统一的大业务运维团队,有利于运维领域的专业性养成;业务运维打散到业务线,会最大限度的降低运维和业务的隔阂(如沟通成本、学习成本等);过渡形态,如果落地效果好,既能保留运维领域的专业性、又能提升公司业务在运维环节的人效。组织形式的选型,本质上是挑选一种更高人效的组织形态,跟公司规模、业务形态、历史沿袭、团队喜好等有很大关系。无论哪一种形式,真心投入的话,应该都能走得通。

对于大型的、平台化的互联网公司,运维能力是一种长期且核心的竞争力,业务运维打散到业务线会严重损害公司在运维领域的专业性,对公司长远发展极为不利,大概率会被摒弃掉。

2019.03.15 运维的套路与创新

经过20多年的发展,运维领域在常见事项的方式方法上已经形成了固定的、可依赖的套路。如,稳定性建设思路、运维效率体系思路、工具平台建设思路。特别的,一本《Google SRE》几乎涵盖了常见的运维最佳实践。

将套路落地是运维的首选。将”套路”运用好后整个运维工作可能就拿到80分了,剩下的20分需要运维工作者深入一线(弄清现状)、大开脑洞(得出创新),将公司的琐碎需求抽象为通用解决方案。创新的程度,展示了运维团队自我突破、不断进取的能力。

长久深陷套路会阻碍创新。过分追求创新,又可能会损害运维本职,两者还是需要酌情权衡的。

2019.03.14 以实事求是的态度建设工具

根据公司自身情况来建设运维工具,这是实事求是的态度在运维领域的一个体现。

运维工具的建设,主要受到如下几个因素的影响:

  • 公司规模,对应的是运维工作总量
  • 业务现状,如业务有是否自运维能力、技术体系是否收敛、运维工具是否多团队共建等
  • 用户习惯,对于有一定历史沿袭的公司,保持产品形态的延续性显得尤为重要
  • 自身能力,公司在运维工具上的资源投入、团队的人员素质等很大程度上决定了工具平台的建设选型
  • 创新环境,不必多说

对高大上的盲目崇拜是人之本能,工具本身也没有绝对的好与坏。满足公司发展和团队成长的诉求,需要根据实际情况做好折中。

2019.02.22 SRE补位思维

在轻量级的运维模式下,SRE对业务的了解一般停留在能够止损的程度,很多时候SRE是业务的一个外挂。

在这种形势下,SRE可以尝试收敛自己的职责,将主要精力投入到做成事的角度。这里的做成事,大部分时候指的是把业务稳定性做好。

做好稳定性工作量会比较大,一个被弱化的SRE团队很难以一己之力搞定全局。SRE可以考虑把自己打造成一个补位者:以做好业务稳定性为目标,适度出让利益,做好各项兜底。

  • 明确目标:达成业务稳定性指标
  • 确定关键:按照稳定性拼图,做好工作目标分解。如,组织建设、机制建设、规范建设、工具建设、RPC框架建设等子任务
  • 不挑肥:对于已经被协作团队主导的事项,SRE转为协助者角色,必须时可出让利益。SRE主动提供必要的资源支持,并做好过程监督、结果监督
  • 不怕瘦:对于无人问津的项目,SRE要勇敢的跳出来担当,做好兜底

补位思维,是做成事态度在SRE工作中的体现。

2019.02.19 工作中的服务者态度

工作的第一原则是,时刻为当前的或者将来的用户着想。比如,

  • 站在继任者的角度写代码
  • 站在用户的角度做产品
  • 站在读者的角度写博客

现在没做好的是站在对方的角度来做人,这是下一步要进步的方向。感谢滴滴,给了我一种可行的工作原则。



管理

2022.08.24 技术评审的局限

技术评审只解决大面的架构风险,不解决细节的逻辑缺陷。负责人要明确主责意识,自己保证设计质量、不能指望他人。

对于技术评审,大家要建立正确的认识。技术评审,不能取代负责人自驱。

2022.08.17 架构和运维的分工

架构主纵,负责数据面、控制面;运维主横,负责管理面。运维根据场景,将纵向烟囱、连接成全局的&可交付的管理面。

组件能清晰的定义数据面、控制面、管理面,应用则相对复杂。应用的共性逻辑,已被抽离出来、建设为中台,如CD、服务治理,这些就是”应用的组件”,举例如下

  • CD:架构建设命令通道、文件通道、数据通道,运维建设CD管控中心
  • 服务治理:如流控,架构建设Mesh网关、劫持数据流提供控制能力,运维建设RD自助的流量管理平台

当前,架构偶尔会建设管理面,运维也会尝试建设控制面,但通常都没有拿到好结果。这里的运维指的是SRE。

2022.08.10 向上管理的协作模型

向上管理的主要内容是做事和沟通。向上管理模型,以沟通方式为横轴、以做事方式为纵轴,做事方式分为事务型、谋划型,沟通方式分为外向型、内敛型。谋划型是指一个人喜欢出主意、不喜欢做具体事务,事务型则相反。外向型指的是一个人乐于横向沟通协作,内敛型则喜欢管好自己。

pict.png

如果上下级的沟通方式一致、都是内敛型或外向型,那么上下级的非正式沟通比较容易合拍;这个时候,你应该有意识的增加非正式沟通、拉近和上级的联系,比如主动发起闲聊等等。如果上下级的沟通方式不一致,则需要下级主动扮演上级的助手,比如上级外向时、下级主动多做一些研究型工作给上级减压,上级内敛时、下级主动多做一些联络型的事情。

如果上下级的做事方式一致、都是谋划型或事务型,那么恭喜你、上级完全懂你在做什么,但也意味着你必须把事情做到最好、要不然上级可能瞧不上你。如果上下级的做事方式不一致,则需要下级主动扮演上级的助手、帮助他补足短板,比如上级擅长出主意、下级就应该多执行,上级擅长执行、下级就要做好幕后军师。协作好了,上级就会更依赖你、对你的授权更充分,你的发展空间也就更大。

带团队的关键点是:定方向、搭团队、做事、沟通。其中,做事、沟通是向上管理的主要内容,因此才有了上述模型。

PS:管理者的任务首先是定方向、搭团队,其次才是做事、沟通。初入管理者要勇敢的下放运营事务、聚焦长期价值。

2022.07.28 改善团队氛围的要点

改善团队氛围的要点,包括但不限于:

  • 分工:工作责任边界清晰
  • 成长:个人成长路径明确
  • 组织:团队内部磨合到位

比较以外的是,分工居然是团队氛围权重最高的项。

2022.07.13 向上管理时要敢SayNO

向上管理时要敢SayNO。你不表达不满,领导就以为你没意见、以后更会理所当然。你表达不满,有可能不被采纳,但连续反馈总能触动领导思考、有可能改善情况。

管理生态的建设,不是一言堂、而是一个反复折中的过程;为了组织健康存续,每个人都应该敢于SayNO、积极暴露问题

2022.06.23 充分放权、做好补位

管理意识上,要开放心态、充分放权,不重复投入、成就下级。在组织结构持续扁平的过程中,发挥好TL的自我价值。开放心态,冒着边缘化的风险充分放权,这是一个煎熬的蜕变。

管理过程中,要识别重点、做好补位,兜底最坏的情况。2022H1的教训是,重点项目的管理过于宽松、卡位不足,失去了对最坏情况的兜底能力,H2做好关键人关键节点的合理卡位。同时避免挤压下级空间。

特别的,放权可以显著提升下属的自信。之前管的细、太扣问题,下属心理负担大,工作结果差。放权给下属自主决策、同时加长了管理跨度,结果较好、下属恢复了自信。管理者重点放在定目标、要结果,过程管理以协助为主。

2022.04.22 管理需求可以被前置消灭

优秀的团队不需要太多管理、设置好目标就行,弱鸡团队才需要各种管理。聪明的TL,首先应该要选对人,把管理需求消灭掉。

2022.04.21 项目验收机制

团队比较弱鸡时,需要设计验收机制,用管理手段、保障项目质量。验收机制,包括:

  • 设计验收:拉会、验收设计,产品功能为主、技术为次。目的是避免返工,适用于核心功能系统
  • 结果验收:拉会、验收功能,要看实物、不要相信他说了什么

以下,是项目验收机制的背景:

在项目管理过程中,经常出现一些蛇尾现象,比如流程没做发布、功能没做验收、改进项长期搁置。平台建设、业务支持等场景也存在类似问题。 针对这个问题,我们约定了严格的验收环节,形式一般是拉会,内容以代码CR、功能验收、心得分享为主。虽然解决了蛇尾问题,但管理成本也挺高,需要继续摸索。

2022.03.02 如何参与技术一线

结论:管理者想要优雅的参与技术一线,就需要

  • ① 目标明确的筛选组织。关注公司的管理容量、组织风格、领导特点,强调人人连接
  • ② 做好个人的管理修养。做到充分放权、降低管理压力,重点卡位、掌握关键一线,经营二手经验

如果职业生涯希望更多的技术成分、而不是纯管理,就需要处理好管理和技术一线的关系。

管理者容易脱离技术一线。可能有如下原因:

  • 组织特点。组织结构、领导风格等因素,可能造成中间层管理者失去人人连接、需求输入不足,造成对一线的疏离
  • 个人投入。管理本身非常消耗精力,忙于管理+管理半径过大 就意味着投在技术上的时间不足
  • 个人错失重点。项目有很多、个人有好恶,稍不留神就会错失重点项目,导致出现重大的一线遗漏,遗漏多了就出问题了

长期脱离一线会带来很多问题。包括但不限于:

  • 专业能力蜕化。不了解产品技术,不了解业务现状,失去技术/架构判断力,技术决策就是空中楼阁
    • 很多管理者就是因为专业能力蜕化,职业生涯过早的进入下坡路
  • 团队价值降低。没有了技术专家/架构能力,技术管理者就成了无根之萍,向上会失去领导信任、向下会失去团队掌控力、横向协作也难以展开

管理者如何优雅的参与一线呢?当前还在实践总结中,有几点体会:

  • 选择组织。选择管理容量足够、组织风格宽松、领导懂得放权的组织,维持好向上的、平级的人人连接。这一项最重要
    • 组织制度一旦开始演化,就会有自我强化、收益递增的特点,很难被改变。所以,做选择、而不是改变
  • 充分放权。维持适度的管理半径(5-10为宜),合理下放部分管理工作,让自己有时间、有精力参与技术建设
  • 重点卡位。识别出关键领域的关键事项,抓大放小、合理卡位,掌握关键一线;识别的过程不能偷懒
  • 二手经验。二手知识足够用,事后找关键角色,给你讲解重点、现场实操,会比亲自参加各种细节沟通更高效

当然,管理特点高度依赖公司资源环境、高度个性化,需要因地制宜。前路漫漫,虽千万人吾往矣!

2022.03.02 如何看待跨级管理

跨级管理,指的是:Leader跨过你、直接调度你的下级资源。跨级管理,原因可能有几个方面:

1、团队规模过小。业务萎缩、团队规模过小时,上级自然有余力向下扩展、跨级管理(水浅王八多)。这是客观原因 2、领导意识不足。领导尚未脱离个人贡献者思维,喜欢直接参与一线、双脚离地就有危险感,这种情况通常发生在新进管理者身上。这是主观原因 3、组织风格使然。强权CxO、过于集中的OKR、细节控等等组织风格,都会加剧跨级。这是组织特点 4、个人掌控欠缺。管理者过分放权、丧失了对关键一线的宏观掌控,久而久之上级就习惯了跨级领导、并理所当然。这是个人原因

对于个人掌控能力欠缺,可以通过管理手段来改善、规避,如加强宏观把控、关键节点验收。加强管理掌控能力的出发点应该是充分的善意和信任,而不是排挤贤能、挤压下一级管理空间。特别的,充分信任的放权并不会直接导致架空、验收不足才会。

2022.02.24 警惕工作中的PUA

知识输入:情感PUA,也称为情感操纵、煤气灯操纵。煤气灯操纵三个阶段就是一个自我认知逐渐瓦解的过程,最初,被操纵者只是轻微的自我怀疑,之后会走向不断自我对话、辩论的阶段,直到最后的自我失去。只要你相信 操纵者的认可能让你提升自信,那你就会成为煤气灯操纵者的潜在对象。

自身经历:细细回想,当年被情感PUA了。当年不懂的、现在明白了,也是莫大的进步。所谓温故而知新。

知识升华:反观工作方面,自己是否在被某种形式的PUA呢?「如果你感觉到,上级的认可让你提升自信、获得快感,上级的怀疑让你迷失自我、精神沮丧,那你很可能正在被PUA」。

2022.02.21 关于红脸白脸的思考

管理者要维持温和的权威,多伴红脸、少伴白脸,多种花、少栽刺,不能代替下级管理者、行使惩罚。

手下一个小组,TL性格温和、无法充分利用人力。我这里看不下去了,就主动跳出来、拌白脸,”压榨”摸鱼的员工。几个月下来,因为无法实时监督、压榨的效果并不好,反而引起了不小的意见。小组TL也没能主动提升管理能力。

这个Bad Case说明,”吃自己的狗粮”、管理责任不能外溢。小TL要尽本分,为结果负责。更上一的管理者,做好红脸、怀柔团队,可能会更好。

2022.02.19 关于管理半径的思考

结论:管理半径不能太小,以5-10人为宜;太小,意味着和一线的人员、业务、技术脱节,会让管理者陷入被动局面。

在向上管理得当的前提下,管理半径不能过小。过小的管理半径,意味着和一线人员、一线业务、一线技术的脱节,让管理者陷入被动局面。

从个人感受来看,3个及以下太小,当初放权过于激进、现在感觉到被动了。师傅建议10人半径,等有机会了要尝试下。

2022.02.15 管理工具之RASCI矩阵

RASCI矩阵的中文名字叫责任分配矩阵。在项目管理活动中,RASCI矩阵在项目初期可以协助规划、澄清成员的权利与责任,也可以在项目中后期作为撕逼依据。RASCI定义如下,

  • R(Responsible)执行人: 干活的
  • A(Accountable/Approve)负责人: 拍板的,定调的,出钱的
  • S(Support)支持者:有钱出钱,有力出力;S角色有时会被省略掉
  • C(Consulted)顾问: 专家团,顾问团
  • I(Informed)知情人: 邮件中被CC到的人

借用FinOps的组织规划图、举个栗子:

page.png

2022.01.29 招人标准的反思

分析了下自2019年建队以来、所有队员的在职情况,有如下几个关键信息:

  • 岗位匹配度高、主观稳定意愿强烈的,能在职2年以上、并成为团队中坚;这类人通常能成长到中高能力,留下来的都不是废柴
    • 个人能力落伍、难于择业的,也可能在职2年以上,关键是发掘与之匹配的低阶岗位
  • 岗位匹配度中高、主观稳定意愿尚可的,2年左右会出现离职潮;2年是个大槛,经过2年积淀、大部分人有条件选择外部诱惑
  • 岗位匹配度低、主观稳定意愿尚可的,最多坚持1年;这类人中,能坚持到1年的、人品都不错
  • 岗位匹配度低,主观稳定意愿一般的,半年内离职;通常是无法适应团队,也有骑驴找马的人

从统计数据看,在职时长主要取决于岗位匹配度、主观稳定意愿,跟个人能力/潜力没有明显的相关性。而我之前一直把个人能力/潜力作为招人的首要因素,看来是错了。接下来会对招人标准做如下改变:

  • 招聘首先看岗位匹配度,其次看主观稳定意愿。不单纯追求能力/潜力,但也要警惕俗人扎堆
  • 将候选人划分为2年期、4年期,事前明确岗位的在职时长预期。2年期是干将,4年期是团队中坚
  • 重点识别骑驴找马的候选人,事前尽量拦截,不幸事后、则永不录用

当然,上述统计结论也可以用做员工的辅导激励,对于岗位匹配度不高的人员要及时调整、避免流失。

岗位匹配度,是管理者对员工和岗位匹配程度的判断,这个判断会结合建队目标,虽然主观、但也比较准确。

2021.12.29 柔情管理不可取

柔情管理不可取。管理者不是和事佬,不能过分依赖员工主动性,对员工不好意思管、不敢管,表面看是柔情、实则是不作为。

柔情管理者,一旦遇到不自觉的人,整个团队的人效就会很差。这是管理事故。

2021.09.29 能力和地位要匹配

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

2021.09.23 隔级指导压力山大

结论:导师和新人的能力代差大于1代时,导师煎熬、新人承压,培养效果会打折扣。隔级指导本质是团队梯度问题。

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

问题出在「隔级指导」上。隔级指导本质是团队梯度问题。导师和新人之间,如果能力代差大于1代、对导师来说就会比较煎熬;如果遇到急脾气的导师,新人就会承压、辅导效果也不会太好。

2021.07.15 团队要适度的讲人情

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

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

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

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

2021.06.16 团队要明确价值定位

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

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

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

2021.04.22 导师对徒弟是有限责任

导师对徒弟是有限责任。如果一年还没达标就放弃吧,不管这人有什么优点;培养不起来,本身就是最大的问题。

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

2021.03.02 高阶招聘

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

2021.02.01 向上管理的职责

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

2020.12.20 成果和贡献的平衡

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

人性倾向于重成果、轻贡献。成果是从0到1的拓新建设,对比显著;贡献是从1到100的持续运营,默默无闻。在没有约束的情况下,公司文化很容易变成重建设、轻运营,重成果、轻贡献;久而久之,没人再愿意做从1到100的事情,而这部分工作是公司运转不可或缺的。

合理的绩效目标制定、结果评估可以缓解这个问题。在绩效目标制定环节,平衡每个人预期的成果、贡献比例,避免明显偏颇;一般的,平台、项目KR是成果,指标、运营KR是贡献。在绩效结果评估环节,管理者要有意识的平衡成果和贡献;比如,采用”OKR客观打分+组长主观打分相结合”的方式,两个排名差异大的成员重新review。

2020.12.10 价值来自关键节点

个人价值, 在于「你是否处于某个关键价值的必经节点」,团队分工亦是如此。

2020.07.19 领导团队的关键点

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

2020.03.25 关于分阶段交付

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

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

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

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

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

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



教育

2022.08.30 科学教育的路径

今天群友马驰发起论点:国内的教科书只会摆共识/让你学习,很少讲述问题来源、也很少提及公式/定理要解决的问题。深以为然。

成人的科学成长路径,大体是:日常实践->抽象问题->学习思考->产出解法->升华认知->指导实践。

对应到小朋友,可以将实践换成精心设计的实验,如:设计问题->引导学习->掌握共识->实验升华。精心设计的实验,也必须来源于现实世界。科学教育的目的,是培养小朋友解决问题的能力,而不是迷信前人故纸堆。

2022.08.30 First

今天开辟教育主题,记录育儿感受。



个人

2022.09.04 房屋养护的思考

在西山林语租住了4+年、上周还房,房东很不满意房屋的保养状态。站在我的角度,多花10%租金就是为了省心、住个好房子,没有养护义务,我也挺愤怒。这件事上,双方都有道理。

在这之前,我完全没有房屋养护的概念。后来找专家了解了下,做的好的业主每周都会请小时工做保洁,云云。我也意识到,房屋养护是我的知识缺陷、需要尽快补起来。

比知识缺陷更有意思的,是愤怒的原因。我本次愤怒的原因是自己的无知,不能理解房东。人的愤怒有多大比例来自无知?非常值得警惕和自省。

2022.07.26 哲思类文章的写作方式

哲思类的文章,一个好的写作方式是:以小故事做引子、深入思考得出认知。

小故事一类的素材,需要日常完成积累。比如,随手做笔记、随手确认出处等。

2022.07.26 砍断厄运链、及时止损

  1. 遇到厄运要坚决斩断厄运链,把损失限制在局部,避免雪崩式灾难。

  2. 止损和认命,是对自我的充分认知,也是对命运的充分敬畏。

  3. 心态会决定命运。人不会总是好运气,也不会永远背运,但坏心态会让厄运不断放大。

上述感慨来自吴军老师,起因是:伯奇尔被费尔蒙特皇后酒店拉黑的故事:

晒香肠时被海鸥偷吃 -> ①打海鸥 -> ②弄脏客房 -> 打海鸥鞋子掉进水沟 -> ③吹风机吹鞋子 -> ④期间接电话 -> 吹风机滑落短路、整个酒店断电 -> 被黑名单

2022.07.20 众利勿为、众争勿往

众利勿为、众争勿往,因为机会偏爱少数人、天上不会掉馅饼。具体的,

  • 空间:机会永远是少的。众人都在争抢时,好运轮到你的概率很小
  • 时间:机会需要提前布局。众人都能看懂、或形成风气时,大概率已经在时间上滞后了
  • 逻辑:事情都是有两面性。如果大家都只看到了好、没看到坏,大概率是认识不深刻、有盲点,潜伏的问题可能会造成严重后果

2022.07.20 西方社会中的善意

今天听吴军的《谷歌方法论》,讲了东西方社会一些共同的善意点,先记录下来、后续有感后再拆解:

  • 勿以小恶而忘大善
    • 反例:一些员工离职,并非下家比前一家更好,仅仅是在前一家遇到了点不爽、就把之前的好忘个精光
    • 之前座右铭是「心怀感恩方能致远」,勿以小恶而忘大善 似乎更贴近我的想法
  • 分享利益,独立决断
    • 分享利益:在大型组织中,用分享利益的方式、促成合力
    • 独立决断:美国各级公权确实民主决策、效率低,但私营企业从来就不曾民主、甚至比中国还独裁;决策就要为结果负责
  • 勿因人之短护己之短,勿以人之短炫己之长
    • 勿因人之短护己之短:因为别人的短处、就尝试掩盖自己的短处。比如,被告的一方抱怨大家在高速上都超速了、他只是跟在别人后面,警察没有抓领头的却抓了他。通常,不问是否有理由做错事、而是确定当前是否做错了事,如果是、该怎么解决就怎么解决,做错事的原因是另一件事
    • 勿以人之短炫己之长:反例,某个人讲,今天我赢了两位世界冠军;原来,他在国际象棋上赢了网球的世界冠军,在网球上赢了国际象棋的世界冠军。专业分工的社会,更关注你的第一专业,把第一专业要做到极致
  • 谋事在人,成事在天
    • 凡事谋事在人,成事在天。对待结果,心态要平和。知道自己不擅长什么事情,而且并不因为这些事情利益大、诱惑大而勉强承受,才是智慧的表现
    • 凡人以识为主,以才为辅。见识比才干更重要

2022.07.14 深度思考

深度思考,是为了得出对客观世界 更深刻、更抽象、更本质的认识。

深度思考,不是一蹴而就的灵感爆发,而是多轮次、反复迭代后的升华。

对于问题思考,遵循「现象 -> 分析 -> 解法」的路径。对于外部输入,遵循「知识输入 -> 自身经历 -> 知识升华」的路径。

2022.01.12 尊重外驱

儿子的幼儿园放寒假,接下来的1.5个月、不再需要早上07:30送上学。缺了这个约束,早上赖床的习惯又回来了、睡醒后总要刷30分钟手机,导致上午到公司的时间推迟到了30分钟。等学校开学,一切又会恢复正常(暑假时已证实)。

自己从来都是强自驱的人,但面对早上赖床,依然需要一个恒定的外驱、来保持习惯。很多好习惯本是逆天而行,依靠本心容易懈怠。

承认人性的合理,跟自己和解;利用外驱维持好习惯,这并不可耻。个人如此,团队亦是如此。

2022.01.09 创投界的技术前瞻性逻辑

对比甲方公司、创投界,两者对新技术的态度迥异。这是为什么呢?

两者拿收益的时代不同。甲方公司利在当下,更愿意使用稳妥的成熟技术,也没必要冒险;甲方往往已经初具规模,因此最低成本的把握当下最重要,偏向更成熟、更便宜的保守技术。创投界则压注将来,技术起点足够先进才能实现未来盈利;创投界的技术变现需要一个实施周期,因此技术起点必须足够前瞻、以至于在公司成熟时正好处于一个技术高峰,否则就是在创造过时的技术,所以创投界必须关注技术的先进性。

看似水火不容的理念,背后都有其自恰的逻辑。同理心思考,挺重要。

2021.07.18 生命的意义

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

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

2021.05.16 职业生涯的长期主义

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

除了明确职业目标、有效利用时间外,也需要尝试增加生命长度。「增加生命长度」,这一点很容易被忽视!

2021.04.22 持续成长最重要

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

2021.04.17 人际资源的年代局限

人际资源有明显的年代局限,一般是上下5年。对应的,个人职业高峰,最多也就维持10年。跨1到2代、建立年轻化的工作联系,有利于打破该局限。需要刻意为之。

2021.04.16 体系化总结和产出

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

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

20220714按:之前更重视形式上的总结,对体系化产出并未做要求。这样不对。体系化产出才是目标,应该更被重视,按照这个要求做了半年、效果显著。

2020.11.30 警惕舒适区

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

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

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

2022.07.18 刻意练习

体系化的成长,来自:1分培训、2分交流、7分练习。刻意练习,就是带着理论做实战、边实战边吸收升华理论;只有升华后的理论,才算真正被吸收。

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

2019.04.10 不纠缠于低层次的人和事

在XJ运维工具团队就职期间,曾因竞争TL和某Peer陷入了半对峙状态,导致大小事陷入了无谓争执,难以做到个人正直、难以摆正公司团队个人的关系。这段时间,我陷入了严重的小格局,成长出现了重大扭曲。之后,我跳出了运维工具团队、去到SRE小组,通过更换空间结束了恶性循环。这之后,虽然也会有些许工作中的争执,但再有没有脱离过正直的初衷。

现在想来,低层次的人和事、往往能唤醒人性的阴暗面,进而拉低一个人的层次、使人陷入小格局。解决的办法,包括

  • 预防:拉起警戒线。识别、回避低层次的人和事
  • 免疫:提升个人修养。降低人性的阴暗面被触发的几率

上述感悟,是被炸哥的文章《不纠缠低层次的人和事》唤起的。

2019.04.04 百度是运维界的黄埔军校

百度背景的运维人员,活跃在国内互联网领域的大部分公司。为什么百度能够成为运维领域的黄埔军校呢?在我看来有如下几个原因,

  • 业务发展早:百度搜索业务的黄金期来的更早,业务推动了运维团队的快速成长
  • 技术成熟快:百度更加技术驱动,能够更好、更快的将运维体系打磨到技术成熟
  • 人才流动频率高:百度身处国内互联网中心(北京)、公司文化层面也比较Open、后期业务增长乏力,这导致运维人才高频流出、加速了对国内互联网领域的占领

回头看看,造就这么一所成功的黄埔军校,既是幸运、又多悲哀!

2019.03.23 个人成长的总结思考

专业知识的积累,有如下两种模式。我个人是螺旋上升模式

  • 连续深入:focus在一个领域上,持续的投入,最后达成专业能力。如,在监控方向一干就是10年
    • 好处:有利于历史资源的积累,过渡相对平滑风险较小
    • 不足:依赖公司在专业领域上持续的投入资源,依赖个人长期坚持的性格
  • 螺旋上升:围绕着一个领域方向,间歇性打转,从不同角度深入对这个领域的沉淀。如,监控干2年、做SRE 2年、再回来做监控
    • 好处:能够做到好奇心和专业性的折中,能够协助建立多领域能力、大局观
    • 不足:在多个子方向间断性投入,往往伴随着历史资源的归零,如知识从头学起、重新组件团队、重新建立专业影响力等

个人成长的突破,有如下关键点,

  • 领路人:在成长的关键节点上,往往需要领路人提供点拨或者资源,帮你完成临门一脚的蜕变。俗称贵人相助
  • 自我进化:反思和开悟的能力,特别是关键节点,可后天培养(批判性思维、深度思考、体系化产出)
  • 进取精神:永不满足的心态,永无休止的努力,破釜沉舟的勇气
  • 心怀感恩:对于帮助过你的人要心怀感恩,特别是勿以小恶而忘大善

这是从滴滴离开前的思考,感谢滴滴给与的成长机会。



思考过程(有的已经被系统化表述,有的可能被证明不完整)

2021.04.01 云原生时代的Devops

云原生时代,Devops的职能从运维团队、转移到了基础设施(云原生)团队。这加剧了运维岗位的运营化。

职能转移,主要动力在于:K8S体系吸收、囊括了Devops建设思想,使得Devops单独存在的必要性降低。

2021.12.30 云原生运维OPaS

全面云化、云原生化的当下,运维导向调整为OPaS,更关注有形运维服务能力沉淀。有形沉淀包括 规范、流程、平台、架构等,不仅仅限于平台。

云原生体系,将原来比较集中的运维价值,打散到了研发各角色,但依然有部分剩余;OPaS尝试将剩余的运维价值再次集中表述。剩余的运维价值,可能包括非服务视角的应用管理(如业务线粒度的管理和运营)、云资源管理、组件服务管理等。

目前能看到,运维价值被打散的过程还在持续,如云资源管理领域的IaC。OPaS并非抱残守缺、顽固不化,而是为了填补进化过程的空白。甚至,OPaS本身也应该参与到运维价值合理打散的过程中。

2020.08.01 运维产出的思考

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

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

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

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

2020.04.01 传统Ops和SRE主要区别

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

20220713按:Ops和SRE的区别,在于组织、分工、技术架构,很少在于主观能动性。康威定律。



Prev     Next