从DevOps状态报告看技术团队的文化建设
本文源自一次内部分享，借由此机会又把历年的DevOps状态报告翻看了一遍，其实大多数时候我们对于DevOps的理解都在于流程，工具，实践这些看得见摸得着的东西，但就像文末的几点思考所说的那样，我们一直相信技术可以改变世界，但很多时候，你要先改变人才能改变世界，而改变人是最难的。所以从文化的层面反过来看这个似曾相识的DevOps，也有不一样的思考和感悟。
一、先来看一些段子
2017年1月31日，全球最大的代码托管协作平台之一的Gitlab出现了一次长达18小时的停机事故，原因居然是一个IT工程师把生产数据库的数据给清空了。
按道理，这种事情虽然难以接受，但其实并不少见。更加严重的是，当Gitlab尝试恢复数据的时候才发现，他们所谓精心设计的多重备份机制，竟然都无法拯救被删除的数据。最夸张的是，直到这会他们才发现，原来数据库定时备份由于升级后工具版本不匹配而一直处于失败状态，原以为邮件会告警这个问题，但巧合再一次出现，针对自动任务的报警也没有生效。
事已至此，要么是隐藏事实然后给外界一个不疼不痒的解释，要么就是完全公开到每一个细节，你会选择怎么处理呢？
Gitlab公司的选择是后者，他们第一时间将系统离线，并将事件的所有细节和分析过程记录在一个公开的谷歌文档中。不仅如此，他们还在世界上最大的视频网站YouTube上对恢复过程进行全程直播，为了避免有些用户不看YouTube，他们还在Twitter上同步更新问题状态。硬生生的将一场事故，变成了一个热门话题，同时在线观看直播的用户超过5000人，甚至一度冲到了热门榜的第二位。可以说，为了透明，他们可以说做到极致了。
不仅如此，在几天后，公司的CEO亲自给出了一篇长达4000字的问题回溯记录，包含问题发生的背景，时间线，核心原因分析，针对每一种备份机制的说明，以及将近20条后续改进事项，由此获取用户的信任和认可，可以说从这一点上，他们真的做到了透明，公开和坦诚相待。
https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/
至于那位倒霉的工程师的结果，对他的惩罚就是强迫看了几十分钟的彩虹猫动画。
Etsy是美国的一家手工艺电商平台，这家公司在15年上市以来，市值一度接近80亿美元。当然，除了他们快速成长的市值以外，最为人称道的就是他们的DevOps能力，那么为什么这些名不见经传的公司能够做到这种程度呢，通过一件小事就能看出来。
你可能不知道的是，一家在线电子商务公司，每日浏览频率最高的单体页面，其实就是网站不可用页面，也就是习惯上的502页面。当Etsy的网站不可用的时候，你看到的是一个小姑娘在织毛衣的画面，而这个毛衣竟然有三只袖子。
三只袖子的毛衣，代表了Etsy对于错误的态度。因为每年公司年终总结大会上都会颁发各种奖项，其中的一个奖项的奖品就是三只袖子的毛衣。获奖者是公司年度引入最大问题的个人，因为在他们看来，犯错误并不是什么大不了的事情。错误本身并不是个人的问题，而是公司系统和制度的问题，正因为有了这样的错误，才给了公司改进和成长的空间，从某种意义上说，这也是一种贡献。一直以来我都以为这是个段子而已，结果这两天Google了一下才发现在2023年他们居然还在颁发这个“三只袖子的毛衣”奖，不仅如此还有人实名上榜，看起来都满开心的样子，所以说到底文化的事情开始都是笑话，但当你一直做一直做，人们才会相信你是玩真的，也会逐渐接受或者拥抱这样的文化，只不过，我们有多少时间等待改变发生，就是另外一个问题了。
二、回到DevOps和研发效能
以上这些“奇葩”段子的背后，其实隐藏着一个共同的价值观，这种价值观源自DevOps文化。想要了解技术团队，就需要首先先了解他们的工作模式，了解他们的思维模式，以至于了解他们的文化中所倡导的价值观。
DevOps是什么？
源于2007年提出的一种软件交付模式，DevOps是Development和Operations的组合词，它是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
--维基百科
DevOps代表了软件交付模式的革新，核心还是为了应对和满足VUCA时代高度不确定性下的快速创新，通过小步快跑，快速迭代，实现快速的用户价值交付和低成本试错。
DevOps状态报告是什么？
简而言之，DevOps状态报告，就是业界最据权威性的调查报告，每年发布一份，可以说是软件从业者的风向标。
2014年Puppet公司联合IT Revolution和Thoughtworks发布DevOps状态报告，至2016年三位主要作者成立DORA（DevOps Research and Assessment）并首次提出DevOps核心结果指标，从此引发业界的广泛关注。
2018年Google Cloud收购DORA，三位灵魂人物也加入Google。从此DevOps状态报告报告正式分家，每年发出两份报告（即Puppet版本和DORA版本），但是由于核心灵魂人物加入Google，Puppet版本逐渐式微，国内以DORA版本为主。
2019年的报告是最后一个原班人马为主要作者输出的报告，此后2020年由于疫情原因报告跳票一次，至2021年恢复后基本是由Google研究员输出内容为主。
从效率和质量维度提出2组4个核心结果指标衡量公司软件交付水平，并且根据业界大量样品调研定义出精英、高中低四个级别，可以作为行业对标参考线。（按此标准京东大致处于中高效能之间的水平）
三、从DevOps状态报告看组织文化建设
DevOps代表了一种组织文化，里面包含了诸多方面，为了客观描述这种文化，早在第一份报告（2014年）就引用了Westrum模型来说明组织文化对组织效能的影响。
1、协作（Transparency、Communication、Trust）
协作是DevOps文化的根基，旨在打破孤岛和筒仓，通过职责共享和团队自治实现快速交付，最典型的代表就是亚马逊所倡导的“You build it，You run it”文化，通过研发自运维的方式来打破对于运维团队的依赖，同时将精力聚焦于打造高效的运维服务能力上（你可以依赖我的平台，但是不能依赖我的人）。无独有偶，在Google的SRE工作模式中，同样提倡有质量的hand-off和hand-back机制，其核心在于我们应该避免让职责转移变成协作的目的，或者用更加通俗的话来说，协作的目的不是甩锅，或者丢炸弹，而是站在全局流程最优的视角，来做合理化的资源分配和分工而已。
变革领导力
在2017年的报告中，提出了变革领导力的概念。所谓变革领导力，是指领导者通过调动员工的价值观和使命感，来激发和鼓励追随者达成更好的效能，并促进广泛的组织变革。其实对于技术管理者而言，他们身兼技术实践和管理实践，除了以服务者的心态为一线员工提供良好支持的同时，还应该鼓励思考目标感，鼓励创新，并建立失败宽容的环境。
高效能团队模式
报告多次引用的《高效能团队模式》一书的内容，描述DevOps所倡导的组织架构，通过清晰定义的组织模式和交互模式，从而减少不必要的团队沟通协作。而在亚马逊的文化中同样倡导Two pizza模式，也就是将团队规模控制在两张披萨能吃饱的水平，从而降低网状沟通所带来的成本。
2、无指责和心理安全（Blameless）
无指责的文化是DevOps文化中最广为流传的内容，在开头Gitlab和Etsy的案例中都可以看到无指责对于构建员工心理安全直观重要。
谷歌在一个为期2年的调查中发现，高效能组织强烈依赖于互信和心理安全的组织文化。特别是心里安全文化可以预期软件效能的提升。
谷歌调研报告原文：https://rework.withgoogle.com/blog/five-keys-to-a-successful-google
另外再2019年的报告中给出了一个提升员工生产力的模型，其中生产力的定义是以最少的干扰和打断完成复杂、耗时任务的能力，也可以理解为顺畅的工作流程或者节奏。
其中有用、易用的工具是至关重要的影响因素，通过调查发现在精英级别的组织中，自研工具和商用工具混用比例最高，因为这样可以最大化服用成熟工具的同时，定制化符合自身诉求的工具箱，另外一方面工具外包的比例是所有级别组织中最低的，也就是说完全采购外部工具的比例最低，因为这并不符合高效能组织的要求。
在Michael Dubakov的软件开发速度一文中，将浪费活动（如低效会议）、沟通协作（跨团队沟通）、返工（需求变更或质量缺陷带来的重复劳动）、系统复杂度和并行任务数量视为提升软件交付速度的核心要点。
这里打个广告，目前行云平台已经提供了计划负载功能，后续还会继续优化团队排期等功能，提升计划的合理性和准确性
http://jagile.jd.com/myzone/department
最近一两年国内公司也在逐步对外发布事故复盘报告，可以视为一种心理安全文化氛围建设的有效手段，对外开放透明并不会影响用户的信任，相反能得到用户的谅解和认可。
3、快速反馈、持续学习和改进（Fast feedback、Continuous learning&improvement）
反馈的重要性再怎么强调都不为过，对个人成长如此，对组织发展亦如此，其实反馈可以融入到工作的方方面面，比如系统层面的监控和改进，个人和管理者的成长和团队发展等等，除此之外持续学习和改进也是DevOps以及诸多方法论中的最终一环，鼓励内部从失败中学习。
在工作中不乏有心人发现问题，甚至在局部改进问题，但是往往缺乏一种机制让这种局部改进可以扩展到全局，一方面减少重复踩坑和重复建设，另外一方面也能最大化改进的效果，从而站在巨人的肩膀上工作。
腾讯海量运维之道中的意识、手段和价值观就来源于一线的创新，并逐步升级为集团共识的技术文化，这些沉淀下来的原则简单易懂，广为流传，从一线中来，到一线中去，包括开源文化，代码评审文化均是如此。
4、自动化（Automation）
Gartner连续两年将平台工程（Platform Engineering）列入10大年度技术战略，同AI、云并列，可见平台工具的重要性与日俱增。
人人都爱自动化，因为可以消除手工劳动，换句话说，好用且易用的工具是提醒效率的基础，这对于任何领域的提效来说都是类似的。DevOps倡导自动化，其实也是作为软件从业人员来说所应该具备的最基本的素质，如果一个开发者没有主动将繁琐重复的工作自动化的欲望，其实是不合格的。在零售乃至集团内部，对于效能工具的建设投入是持续和坚定的，这也是行云平台存在的意义之所在，我们团队在这个过程中扮演了非常重要的角色，既是平台的建设者，也是平台的设计者和倡导者。
凡是均有两面性，之前也思考过自动化的反面，对于效能平台来说，很大程度上是在平衡与妥协中，追求最佳的解决方案。
我们都是自动化的信徒，并将自动化等同于效率，以往的做事方式都是先进行一线田野调查，总结线下工作流程，把这些流程搬到线上，然后通过自动化改进这个流程的执行效率，这样做固然没错，然而这个假设前提是，团队在线下工作的过程中，已经沉淀出一套切实可行的方法论流程，并且这个方法论流程是经过时间检验，可靠可信赖的。但你有没有想过，这里面其实存在几个问题： 1. 每个团队都会基于自己的习惯和资源来磨合自己的流程，这也就意味着在缺乏顶层设计和强力推动下，每个团队的流程和做事习惯可能都不一样，工具很难统一这个习惯，即便去做兼容也会花费不菲的代价。 2. 团队现行的流程并不一定是最优的，而是在已有的约束下求解，这些约束包括的团队的组织架构职责分工，包括现有的人力资源和能力水平，包括了过往的种种习惯的延续和传承，存在即合理但不一定是对的，如果工具仅仅是翻译这个过程，其实产生的价值非常有限，因为价值往往来源于创新。 3. 站在全局视角来看，局部效率提升和全局效率提升是潜在冲突的，这也就意味着，当我们面向全局来设计流程的时候，很有可能会损害某些团队的利益/指标，这样会对流程推广落地带来很多不稳定因素。 4. 即便解决了以上问题，但是自动化意味着人的关注度降低，虽然自动化只是为了提效而不是为了转移工作量，但随着人的关注度降低，以及自动化带来的提效，反而会加剧流程的固化，更加没有人有动力来优化这个流程。 所以，单纯的追求自动化率不断提升，并不是一个终极指标，而只是过程中的尝试而已，只不过我们很容易把过程的价值跟结果的价值等同起来，当我们拿到结果的价值，过程也就自然而然的被close掉了，然而流程和效率的优化是永无止境的过程，也就是说我们会永远在路上，这对于人性的考验反而是做提效工作者最大的挑战。
