量体裁衣：将DevOps转型融入到企业文化-白红宇

量体裁衣：将DevOps转型融入到企业文化

阅读量：6324 次

发布时间：2019-06-22

本文共 8955 字，大约阅读时间需要 29 分钟。

\

本文要点
\

理解为何一个公司成功的战略转变必须将企业文化纳入考虑 \

了解DevOps转型是创建高效机构的战略性主张之一 \

学习衡量和可视化企业文化的工具 \

对某公司实施DevOps转型的案例研究 \

对如何影响企业文化的建议

“2016 Devops 状态报告”中提出了关于企业文化的Westrum模型[1]。该模型聚焦于用信息流通、高度合作和信任作为Devops在公司内能成功的预测因素。它是一个很好的将来状态设计工具，但是，它并不能告诉你的公司目前如何。而且，对于如何影响企业文化以及应该如何改变企业文化，它没有给出建议。\

本文中提议了一种替代模型（也许可以互补）。该模型是由Cameron和Quinn提出来的[2]，它考虑一个公司是专注于灵活性还是稳定性，以及它的运营是对内集中还是对外集中。我所就职的Seqr公司一直在持续地进行DevOps转型，此文中我将展示该模型在Seqr的应用结果。我的经验表明，应以一个机构现有的企业文化作为起点，它决定了如何影响企业文化来创建一个高效机构。之所以选择Westrum模型的替代模型，是因为它提供了衡量和可视化企业文化的工具。\

为什么企业文化重要

在过去的几十年中，公司内发生了四大变革主张：战略性规划，总质量管理，再工程化和缩减规模。它们的目的在于提高经济效益。然而，其中75%或是失败或是产生了足以威胁公司生存的严重问题[2]。忽视公司的企业文化是最常被提及的失败原因。\

我的观察也证实了这一点。我看到有些等级制和官僚作风的机构试图将Scrum用于团队级别，而不去影响可支持这些改变的主管级别。在这种机构内，敏捷教练们向员工们教授勇气、专注、承诺、尊重和公开。然而，他们所为之工作的系统通常提倡办公室政治、把责任推卸给他人及逐级上报，这些与上述的价值观相悖。\

企业文化貌似难以理解，无论如何，领导者们都不应该低估它的重要性。文化可支持公司的战略主张或让其注定失败。在后面的篇幅中，本文将证明Devops转型是创建高效机构的一项策略。\

企业文化在Seqr常被提及。譬如，当挑选某人担任管理职能以促进大家向理想的方向做出改变时，我们会考虑到我们的企业文化。此外，当我们需要进行内部重组以实现由超前的新兴机遇所界定的新的商业需求时，我们也将企业文化列入考虑。总之，当做出某个特定的商业决策时，对企业文化的认识会告诉我们如何行动。\

什么是DevOps转型以及如何定义高效机构

什么是高效机构？根据\"2016 DevOpes状态报告”[1]，高效机构被描述为这种机构：按需部署（每天有多次部署），从代码提交到代码在产品中运行所间隔的时间不超过1小时，平均恢复时间少于一小时，而且变更失败率低于15%。高性能机构们在吞吐量和稳定性上都表现得很好，这也证明了这并不是一个零和游戏。能达到高效的原因在于，持续交付背后的技术使得能够在给出高质量产品的同时也能更频繁地部署。[4]\

根据我的经验， DevOps转型需要企业各个级别的全面的努力来打造高效机构。其中一种开始实施DevOps的方法就是教企业通过迭代和逐步增长的方式来开发其产品。通常，这就意味着，在公司内（不仅仅是在工程师之间）采用Scrum来在每个sprint交付商业价值。时不时地，公司会意识到，多亏Scrum，因为它们的主要的挑战是不能按照市场上有竞争力优势的节奏来完成交付。\

Seqr是以一次上线（rollout）所需要的时间以及上线的频率来定义高性能的。定期每隔一段时间举行一次上线（我们大概是每周一次），交付自上次上线之后所完成的任何功能（feature）、改进或错误修正。团队将sprint的部分时间放在改进上，从而减少上线时间。如果上线时间变得足够小，上线就会被按需部署所代替。一旦我们达到每天上线一次，我们将会考虑作为一个公司我们是否令用户满意了，或者我们是否应该在工程方面做出更多的努力来让分部门的每一个提交上线。\

我很赞同Jez Humble [4]的看法：架构不足和文化不足这两大阻碍导致持续交付（Continuous Delivery，它是DevOps的非常重要的概念）不起作用。前者意味着，可测试性、可部署性和可监控性经常不是一个系统架构所主要考虑的。后者代表着，员工不能感受到有必要去更频繁地交付、更快地收集反馈意见和持续地改进他们的工作。架构转型的内容不在此文的范围之内。我们将聚焦在如何衡量企业文化和如何定义潜在的改变方向从而来支持DevOps转型。\

竞争价值框架解析

竞争价值框架[2]定义了四种文化类型：大家庭型（clan），灵活型（adhocracy），市场型（market）和等级型（hierarchy）。它们的特点都在于独特的价值观驱动，对效益来源的假设，以及占主导地位的领导能力类型和方向类型。\

大家庭型企业文化以合作为中心。它的主要假设是企业的效益源自感到满意的和忠诚的员工们。员工参与和卷入到公司的决策过程中，引来了他们的忠诚和授权。有着大家庭企业文化的公司，其领导者们是团队建设者、导师或教练，帮助每个员工和团队向前发展。\

灵活型企业文化通常与企业家精神和创新挂钩。对它而言重要的是前沿的想法和创新的解决方法以解决那些可产生新机遇的问题。在这类公司内，领导者们主要是能启发他人的创新者和有远见的人。\

市场型企业文化关注实现目标、在竞争中获胜、以及提高像市场占有率或ROI这些可测量的成果。它的主要假设是，无论是内部竞争还是外部竞争，它们都是带来效益的生产率的来源。这类文化的领导者们喜欢竞争并且在很多阻碍下仍能交付结果。\

等级型企业文化赞扬可预测性、时间性和效率。通过控制谁的目标是清除冗余和浪费来获得效益。因此，这类文化的领导者们通常是很好的组织者和协调者，他们监控程序是否被遵循以及规则是否被打破。\

表1总结了这四种企业文化概况：\

表1: 竞争价值框架中的四种文化类型，来源：[2]\

除了四类企业文化的明显的区别，我们也需要理解划分这些文化的两个区分的维度。其中一个区分的效益标准是公司是动态的、敏捷的和适应性强的（大家庭型文化，灵活型企业文化）或者可预测的和稳定的（等机型企业文化，市场型企业文化）。前两种企业文化，如果它们可以自我转型来跟随所处环境的变化，就被认为是很有效果的。很多初创业公司和NGO有这种特征。后两种企业文化，如果它们获得的结果是持久的，就被认为是成功的。这种特征在政府机构和大学很典型。\

另一个区分的效益标准是内部导向（大家庭型和等级型企业文化）与外部导向（灵活型和市场型企业文化）。前者们聚焦在以完整和一致为效益来源。而后者们重视外部世界，将获得成功归功于竞争和市场。\

这两个维度（灵活性对稳定性，内部导向对外部导向）交叉产生一些独特的企业文化。譬如，大家庭型企业文化代表灵活性和内部导向。另一方面，市场型文化代表着稳定性和外部导向。重要的一点是，多种不同的文化能在公司内共存。譬如，在一个典型的企业内，很可能销售部门采用市场型企业文化，GRC（治理，风险和法规遵从）部门采用等级型企业文化，研发部门采用灵活型企业文化，而人力资源部门是大家庭型文化。据我的观察，这种企业文化上的分歧可能导致公司内部的摩擦，当员工把精力浪费在冲突上时就会引起效益的下降。领导者们对不同文化的意识和共鸣能帮助公司利用分歧并正确地应对它。\

Cameron和Quinn提出了衡量公司拥有何种企业文化的问卷调查表[2]，该表如图1所示。\

图1：企业文化评估工具，来源：[2]\

员工被要求回答下面6个问题：公司的主要特征、领导力、对员工的管理、凝聚力、战略重点和成功的标准。对每一个问题，他们将100分分配给答案A、B、C或D。A代表大家庭型企业文化，B代表灵活型企业文化，C代表市场型企业文化，D是等级型企业文化。“Now”这一列代表被调查者对公司目前的看法。“Preferred”这一列代表被调查者认为要在将来成功的话公司应该是什么样的。所有问题的答案A、B、C和D的结果的平均值画成一个图表，来描述一个公司的独特的文化类型。\

Seqr 案例研究

Seqr的软件工程部门、运营部门和产品管理部门填写了调查表。一共大概有60人。\

该公司的组织结构如下。软件工程由团队和管理层构成。团队是跨功能性的，由软件工程师，QA工程师和系统管理员组成。产品负责人准备好一个确定了优先级的积压任务表（backlog）给软件工程团队，而团队的目标是领取积压任务并编程实现端到端的新特征，从想法上至该特征被部署到产品中并根据商业目标监控其性能以及修改错误。全职的敏捷教练一方面是团队的成员，另一方面也是管理团队的一部分。他们与团队一起工作，但也与公司其他部门譬如产品管理、客服、市场或销售部门工作。有些软件工程经理们的职责很广，从招聘、挑选新员工并让他们适应公司、员工管理者（解决是否可能让员工把个人目标与公司的商业目标相结合）到缩小技术与公司商业世界之间的差别。运营团队，通常也被称为网站可靠性工程（Site Reliability Engineering）团队或SRE，由系统管理员组成，他们主要负责网站可靠性和环境的预防措施，是公司运营的中坚力量。产品管理团队由产品负责人组成，他们管理内部和外部的利益相关者，将他们的需求映射到backlog并提供给软件工程团队。关于Seqr（之前的名称是Seamless）的更多细节和它的演变可参见InfoQ往期文章[5]和[6].\

图3和图4分别给出了运营团队和软件工程团队的企业文化概况，每个图中将团队和领导者区分开了。\

图3：网站可靠性团队和领导者的文化概况\

图4：软件工程部门（团队，敏捷教练以及经理）的文化概况\

就软件工程部门而言，大家庭型企业文化与灵活型企业文化混杂在一起，还夹杂一丁点市场型文化，好消息是员工对这种文化很满意。敏捷教练们对团队的观点也类似。但是经理们看问题不同。他们看到的是以大家庭型企业文化为主导，觉得有必要将其改为将大家庭型、灵活型和市场型企业文化同等地混合在一起。\

我们讨论了团队和管理层对现有文化的看法的差异。从管理层角度出发，Seqr是一个在高度不稳定市场下运营的前沿公司。威胁可能来自多个不同的方向：监管者、直接或间接竞争者、或者客户习惯的更改。只有能足够快速地改变方向的高效能公司才能在市场上存活下来。如果我们的产品不是通过敏捷开发来增量开发，如果我们不能很频繁的交付（譬如，每周一次），存活下来是不可能的。因此，在Seqr，我们相信DevOps转型是创建高效机构的答案之一。\

Seqr的DevOps转型

建立持续交付是DevOps转型的十分重要的里程碑之一，而Seqr也不例外。暂时忽略文化因素，达到成熟的持续交付需要改变设计和架构、组建与部署、测试和验证及信息和报告[7]。根据我作为咨询师时的观察，我从没见过哪个公司采用同一个交付管道。而且，我经常看到专家们争论应采用什么样的技术上的改变来在公司内建立成功的持续交付。在Seqr，我们经常观察到对同一个问题有很多解决办法。事实上，这种实验的浮现（而不是事先就众所周知）表明我们在处理Cynefin[8]中所定义的复杂领域。处理复杂领域的策略是频繁地执行“调查-感知-响应”这一循环过程。我们认识到实验是必须的，因为没有证据表明哪些是为我们公司的独特环境所定义的最好的或好的实验。而做实验在灵活型文化中很典型。\

对于一个像Seqr这样的公司，理解市场何时改变或新的机会何时出现是非常关键的。员工需要对客户、竞争和市场保持好奇心。这种能将自身与商业周围环境相关联的专注是典型的市场型文化。\

如Learn Enterprise[9]书中所观察到的，如果一个机构由小的、分散的、自主的团队构成，它就能快速地增大规模。权力下放原则适用于这类机构，“默认情况下，应由直接受决定影响的人来作出决定。在官僚机构中，地方级别的人员不能有效地完成某些工作，而高级别人员应该只做这些工作”。这种方式的基础在于有自信的团队，团队有权去尝试和作出与架构相关的决定等。我们在Seqr的经验显示，大家庭型文化支持这种信心。在公司内，关键的技术上的决策不是由一个单独的个体来作出的，通常都是团队的努力。譬如，由架构师独自作出的决定，相比而言需要更多的时间。然而，我们认为，让受影响的人们来影响决策会更有价值，因为这是他们自己的决定，所以会支持它而不是反对它。\

最终，在Seqr，我们有了与公司背景相吻合的理想的文化概况。该文化概况如图5所示。\

图5：Seqr中支持DevOps变革的理想的文化概况\

有两点需要强调。第一，对DevOps转型，并没有一个普遍通用的文化概况。我们对Seqr的信任将帮助我们获得成功，所以这一点不应该被复制。但是希望这背后的推理对其他公司和他们的情况有用。\

第二，文化属于复杂的领域（Cynefin）。因此，“文化的改变对目前而言是一个演化的过程，并不是一个理想化的将来状态设计”[10]。它的意思是说，Seqr的DevOps转型所用到的文化概况应该被看作为我们希望改变的方向，而不是一个精确地详细说明的目标。\

我们如何进行文化改变？那种认为管理者们能自己改变机构的企业文化的想法太天真。他们能最大程度的影响企业文化。由于文化是相互作用的一个很新兴的属性，可以从好几个方面来影响它[10]。\

如果你听听公司内的故事，你就能发现用来应对现实问题和人之间的问题的模式。因此，要实现改变，很重要的一点是创建新的有效的故事来展示解决现有问题的不同的方法。当这些完成后，它们就成为新的参考点，能提供新一套方法来产生新一套行为从而改变文化。\

Seqr的DevOps转型起源于一个实验。在这个实验中，两个团队开始负责一个解决方案的开发，以及将其交付给产品并维护它。这个实验被证明是成功的，鼓励我们在公司的所有团队中重复该实验。结果是整个部门的团队，包括软件工程师、QA工程师和系统管理员，被重组为真正的跨功能团队。此外，我们也充分利用那些被冗长会议所占据的人们，他们试图解决某特定问题，往往因为问题的复杂度以找不到解决办法而告终。因此，我们建议，从会议中提议的那些合理方法中挑出一个来实践一下，而不要花过多的时间在讨论上。唯一的条件是，两周后我们会返回到结果，认真测量结果。这将帮助我们看看实验是成功或失败。\

这些实验（顺便提一下，它们是灵活型文化的典型）帮助我们更快地工作，我们能够更频繁地采取行动，而不是困于寻求最完美解决方案的无止境的讨论中。多亏这种方法，我们讲下面的这些技术概念引入到了日常工作中。\

用Docker来集装箱化部分架构， \

向统一的环境促进（开发、准生产和生产）， \

引入特性开关和金丝雀（canary）发布[11], \

使用实际移动设备上的Appium进行生产环境的监控，等等。

这些实验也导致交付的改变：\

停止了“开始特性”的说法，开始使用“完成特性”[12]， \

在实现sprint目标时引入了WIP限制， \

将发布与上线分开， \

软件工程团队从SRE团队接手应用程序监控以缩短反馈环， \

万一发生了产品环境中的重大失败等，我们引入了无罪事后调查

我们采取的另外一个影响文化改变的步骤是，用放宽和增强的方式来管理自然的约束。譬如，不同于其他软件工程团队只负责开发，前面提到的两个团队需要负责整个交付过程：开发、测试、部署和监控。实际原因是运维团队里没有足够多的系统管理员们来帮助他们交付和监控。因此，这两个团队做出了相应的反应，证明了他们也可能做出可测试的、可部署的和可监控的软件，没有必要把部分工作移交给专业团队。\

因为文化是交互中自然形成的，所以需要好好管理它。这里有一个例子。让新员工适应环境时，我们将他们和保持理想文化的员工混合在一起。因此，新员工首先学习处理问题的理想的模式并理解实际。这一点对波兰式文化尤其重要（软件工程、运营和产品管理位于我们在波兰Lodz市的办公室；本文作者是波兰人）。由于低包容，波兰人倾向于用愤世嫉俗和悲观情绪来应对商业运作的不稳定性。这种是全国性的文化趋势，如果任其发展则可能是破坏性的。\

对公司而言，能够辨别出公司内出现了理想的文化[14]也是很关键的。譬如，当团队从SRE团队接手了监控应用程序的职责时，团队里的员工有两种解决方法。一些人让管理层来指定谁应当去值班。其他人认为由团队来决定谁去负责监控。前者要求等级型文化，领导者是协调者；后者要求大家庭型文化，领导者是支持团队决策的促进者。根据我们理想的文化概况，管理层决定支持后者来解决问题。如此，管理层影响文化向大家庭型改变。\

结论

有时候DevOps转型局限于实现特定的技术和实践。我们在最开始的方法中忽略了文化，遇到了人们对所引进的改变有所抵触。而这些反过来导致了不理想的结果（如：低部署频率）。我们观察到，很自然地让人们参与到持续改进交付管道，这种现象目前只能在公司内一部分工程师中见到。当我们把文化视角加入到DevOps转型中，我们就开始理解为什么有些特定的主张不起作用以及应该如何引导它们。\

通过DevOps来打造一个高效机构，往往需要改变其企业文化。据我的经验，这是转型中最困难的挑战之一。首先，它需要领导者们理解如何影响企业文化成为一个复杂的可适应的系统。应对文化这种无形的物质，需要领导者之间有各种各样的软技能来与人和团队打交道。我们要能够把这种软技能与工程世界相结合，并认识到这两者如何互补。最终，在目标和理解频繁实验、短反馈环、缺少能力孤岛和共享的（而不是淡化的）责任等等背后的价值方面，整个机构内必须一致。\

有人可能有这样的印象，认为企业文化是DevOps转型中所有问题的解决方案。它当然不是。它是基石，要么增强公司的战略主张，要么让其注定失败。如果一个机构的改变也考虑到了文化，那么文化很有可能会令其事半功倍。\

文化是我们所获得的结果背后的原因之一。然而，没有员工（不仅仅是工程师们，还有敏捷教练们）以及他们的专家知识和经验来执行DevOps转型，我们是无法达到这些结果的。结果如图6所示。\

图6：DevOps变革中的Rollout统计值（时间跨度：约一年）\

图6中，每个横方块代表上线程序中的一个步骤。为了不泄露我们产品环境的技术细节，这里就不解释它们的含义了。然而，重要的是，平均上线时间很显著的减少了，从大约80小时降到了5-10小时。因为这些改进，上线从而变得更频繁。而且，上线变得更稳定，因而从所需时间而言它们变得可预测了。考虑到敏捷开发团队在任务规划之后的提交承诺，他们需要一定程度的可预测性，这一点很重要。上线是敏捷开发团队的职责，可能会影响到Sprint的其他目标。\

随着连续不断的上线，有些障碍就消失了，其主要原因有两点：（1）上线程序（包括架构）的简化；（2）人工程序的自动化。就简化而言，重新设计上线程序来减少步骤因此减少复杂度。另一方面，对人工程序的自动化主要是针对测试和部署，从而降低其复杂度。在整个转型中一直保持着低失败率。\

前面提到我们还在继续进行DevOps转型以提高上线频率和发布质量。因此，这个过程是持续的，但我们所决定选择的方向看起来前景一片光明。\

参考文献

Puppet, Inc., DevOps Research and Assessment, \

Kim Cameron, Robert Quinn, Diagnosing and Chaning Organizational Culture: based on the competing values framework, Jossey-Bass, 2006\

Dave West, \

Jez Humble, , Lean Agile Scotland 2016\

M.Lundgren, T.Pajak, \

T.Pajak, \

A.Rehn, T.Palmborg, P.Bostrom, \

D.Snowden, M.Boone, \

J.Humble, J.Molesky, B.O'Reilly, Lean Enterprise: How High Performance Organizations Innovate At Scale, O'Reilly Media, 2014\

D.Snoweden, \

D.Sato, \

H.Kniberg, , Agile By Example 2016\

G.Hofstede, \

P.Brodzinski,

关于作者

Tomek Paj?k (来自波兰Lodz市）有好几个IT职位：软件工程师， IT架构师，以及工程团队领导。同时，他是金融科技公司的软件工程经理，该公司有自己的研发产品，在欧洲和美国提供移动支付解决方案。为了获得竞争优势，他将Lean Startup和Scrum用于产品开发，并将DevOps用于强健的IT性能。他也是的一名教练，帮助公司通过采用敏捷/精益的概念和特定技术来改进商业。Tomek获得Akademia Leona Kozminskiego的MBA，以及Technical University of Lodz的电信和计算机硕士学位。他在Agile Lean Europe、Agile Cambridge、Agile By Example、Agile Central Europe、DevOpsDays、 Agile Eastern Europe、Atmosphere 等等国际会议上都有发言。可通过和Twitter（@tomekatwork）联系他。\