运维建设之运营思考

导读

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


运维

2022.04.15 重复造轮子是否合理?

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

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

pict.png

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

2022.04.11 如何区分监控(monitoring)和可观测(observability)

从平台功能看,监控是可观测的子集。除监控外,可观测还囊括了Logging、Tracing、Event等APM能力。

从业务场景看,监控用于稳定性管理,故障处理时发现问题;可观测用于质量管理,从外部的数据特征、推断应用的内部状态,使用场景包括性能优化、故障处理。

从实现思路看,监控侧重于问题驱动,case by case针对性加强;可观测也会问题驱动,但同时强调数据挖掘的价值,先有数据、再发掘价值。

总的来说,相比监控,可观测是一个更加全面的概念。平台能力从Metric扩展到Logging、Tracing、Event,业务场景从稳定性领域、扩展到应用质量管理,实现思路从问题驱动、升级到数据挖掘。但,站在运维的角度,这个调整并不友好,可观测弱化了领域专业性,也让监控从一个重运维的能力、变成了质量管理的一个子集。

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

最近看HashiCorp联创采访,其对工具输入的理解挺有意思: Knowledge should be represented as Code,典型代表就是IaC。工具的输入方式,先后有Env、Config、命令行、API接口、UI交互等形式。Code方式在「知识沉淀+传播」上有优势,收到了创投界追捧。

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

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

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

工具类产品比拼的不是单纯的性能,更是工具背后的、代表新的生产方式的方法论。把最佳实践抽象成方法论,难度不比性能提升小。一旦让这个方法论成为事实标准,才是真正的护城河。

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

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

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

  • 资源投入不足,重业务、轻运营,没有足够的资源支持运维工作者做长做深。这是中国互联网基础设施的通病,不限于运维领域
  • 领域深度不够,绝大部分10年老兵都会遇到瓶颈、不得不转行。运维的场景足够广,但因为缺少软件工程思维,运维老兵不知道如何深挖、只能选择附庸业务,最后自己的价值越做越薄、不得不转行
  • 无法自我革新,重运营让运维领域成为应用学科、而不是基础学科。从标准化之后,运维领域的每次成长都来自跨领域输入,如自动化依赖应用架构、数字化依赖大数据、智能化依赖AI

运维领域想要有所作为,可能要分出一部分人:在充分了解运维场景之后,吸收系统的软件工程知识,养成更强的基础学科意识,在一个更高的维度完成对运维工作的系统化抽象。

2021.12.30 云原生运维OPaS

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

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

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

2021.12.29 中国不需要照搬AWS

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

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

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

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 一线同事能力较差时,如何保证结果质量

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

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

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


管理

2022.03.02 如何看待架空

架空,很多时候是一种管理感觉,最直接的形式是常态的跨级沟通,即:Leader跨过你、直接跟你的下级沟通。

跨级沟通,原因可能有几个方面:

1、个人放权太多、验收不足,丧失了对关键一线的宏观掌控;久而久之,你的Leader习惯了跨级获取信息、推动事情,最终形成跨级沟通的事实 2、你的Leader尚未脱离个人贡献者思维,喜欢直接接手干,管理方式不成熟 3、你的Leader的Leader是细节控,导致你的Leader不得不频繁介入一线实施、了解一手情况

2和3是组织特点,属于不可抗力,不再讨论。

1完全受个人主导,可以改善、规避。如果已经发生,解决之道在于加强宏观把控、而不在跳过下级重归一线。特别的,充分信任的放权,并不会直接导致架空,验收不足才会。

管理的出发点,应该是充分信任、应该是充分善意。心胸和气度,决定了管理的高度。

2022.02.21 白脸黑脸的思考

更高一级的管理者,要拌白脸、而不是黑脸。

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

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

2022.02.20 管理和技术一线的关系

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

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

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

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

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

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

  • 选择组织。为避免成为失去人人连接的中间层,要选择组织架构合理、领导懂得放权的团队。这是最重要的外因
  • 做好管理。管理半径不能过小,目的也是为了保持人人连接。这是最重要的内因
  • 识别重点。识别出关键领域的关键方向,对项目抓大放小、没必要掌握所有一线经验。识别的过程,不能偷懒
  • 提高效率。事后找关键角色,给你讲解重点、现场实操,会比亲自参加各种细节沟通更高效;二手知识足够用

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

2022.02.19 关于管理半径的思考

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

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

2022.02.15 管理工具之RACI矩阵

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

RACI定义如下,

  • R(Responsible)执行人: 干活的
  • A(Accountable/Approve)负责人: 拍板的,定调的,出钱的
  • C(Consulted)顾问: 专家团
  • I(Informed)知情人: 邮件中被CC的达人

RACI矩阵,有时又被称为RASCI矩阵、多了一个S,

  • S(Support)支持者:有钱出钱,有力出力

粗粗的盘点一下,RASCI矩阵用的更多(即S角色大量存在)。借用FinOps的组织规划图、举个栗子:

page.png

2022.01.29 招人标准的反思

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

  • 岗位匹配度高的高人、个人稳定性意愿高的中人、别无去处能力落伍的人,能在职2年以上、并成为团队中坚;即使能力落伍的人,也能发挥不错的价值
  • 岗位匹配度中高、个人稳定性尚可的,2年左右会出现离职潮;2年基本是个大槛,经过2年积淀、大部分人有条件选择外部诱惑
  • 岗位匹配度低、个人有稳定性意愿的,最多坚持1年;这类人,人品不错
  • 岗位匹配度低,个人稳定性一般的,半年内离职;通常是无法适应团队,也有骑驴找马的人

非常意外的是,在职时长跟能力/潜力没有明显的相关性,而我一直把能力/潜力作为招人的首要因素。因此,接下来会对招人标准做如下改变:

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

2022.01.12 习惯的保持也需要外驱

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

自己从来都是强自驱的人,但面对早上赖床,依然需要一个恒定的外驱、来保持习惯。很多好习惯,本是逆天性而行、依靠本心容易懈怠,需要恒定的外驱。个人如此,团队亦是如此。团队需要哪些恒定外驱呢?接下来要明确List下。

2021.12.29 柔情管理不可取

管理者做一个和事佬,对员工不好意思管、不敢管,表面上看柔情、其实是不作为。

柔情管理者,过分依赖员工的个人主动性,一旦遇到不自觉的人,整个团队的人效就会很差。柔情管理不可取。

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 领导团队的关键点

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


个人

2022.02.24 情感PUA

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

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

反观现在,有没有在不自觉的PUA他人呢?非常值得警惕。

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