有幸参加了高效运维社区组织在2017年2月24到26日的DevOps Master认证培训。

在原有的印像中，认为所谓的DevOps无非是“开发”+“运维”，即运维要懂开发，能利用编程语言去实现平台运维自动化。但通过这几天的培训，对DevOps有了更清晰的认识：DevOps是一种文化，是一种跨团队(Cross-Team)的团队协作，通过单件流(one-piece-flow)，JKK的理论，在保证业务连续性(Business Continuity) 的前提下，实现持续集成(Continuous Integration)、持续交付(Continuous Delivery)的要求，最终实现提升业务产量(Business Outcome)的目标。

在这次培训中，印像最深刻的是“凤凰项目(Phoenix Project)沙盘”（以下简称PP沙盘）。和几位同学私底下闲聊，我们都认为这是一个“针对于企业的高级版桌游”（据说每个人实际的参与价格要500元）。

像传统的桌游一样，PP沙盘中有很多角色，由上自下的角色分布为：

CEO、CISO

CIO、CFO、Retail Operation、Human Resources

VP of IT Operation（VP）、Application Department（AD）、IT Support（ITS）、Technology Operation（TO）、IT Test Team（ITT）、Change Management（CM）

另外在Technology Operation中还有额外的一个Lead Engineer。

每个角色的精力是有限的（DevOps的文化中，强调Work-Life balance，不提倡Overtime），也就意味着在一个周期内，只能承受一定的工作量（Workload）。而CEO会在一个周期内同时下发多个任务，而这些任务的工作量总和可能会大于这个周期内所有人可承受的工作量总和（这也非常符合现实中的情况）。

通过PP沙盘，总结了出以下最佳实践，希望能够带给大家一些感悟，帮助提升IT持续交付的能力、提高业务产出。

思考一：使用可视化看板来解决业务视角与IT视角的差异性。

业务驱动IT，是一个在现实工作中很普遍的问题。

由于种种原因（如获客引流、提升企业形象、新功能开发等），业务部门会决定对一个项目立项与否。而此时，由于IT部门并未参与前期的项目需求讨论，业务部门对于整个项目所需要消耗的人天、乃至投入的资金是不得而知的。

而与此同时，IT可能同时面对着几十个甚至几百个这样的项目。由于人力资源的局限性，IT可承受的工作量是有限的（且通常会远远小于业务的需求量）。因此必须进行取舍。

可视化看板能很好的解决这个问题。

可视化看板可以以全局的角度去衡量每个项目在每个条线所需要的人天及项目进度。去权衡该做哪些项目，该放弃哪些项目。以达到业务产量最大化。

思考二：充分进行团队协作，从而有效地保护瓶颈点。

Lead Engineer是PP沙盘一开始的一个瓶颈点：

1、很多任务只能由Lead Engineer去完成，其他人没有Lead Engineer的能力

2、Lead Engineer可承受的工作量是所有角色中最小的

按照瓶颈理论(Theory of Constraints,TOC)，需要提高这个短板。

而通过知识共享以及培训，可以实现与TO、ITS团队协作（Collaboration），形成一个资源共享池，以在一定的范围内进行工作量的平衡。

现实中，每个团队也会有一两个这样的Superstar，释放他们的工作量，同时将他们的知识共享给其他teamplayer，会有效提供整个团队的效率和专业水平。

思考三：指定把关人(Gatekeeper)，并对于每次变更进行记录。

在PP沙盘中，当一个项目被确定要进行执行后，会把具体的任务分解到各个团队中。但是由于事先没有良好的变更记录，导致某些任务被重复执行，浪费了工作量。

指定把关人，决定哪些做，哪些不做，并对变更操作进行记录，可以提高变更操作的有效性和准确性。

思考四：平衡工作量，适当取舍，学会说“不”，使用单件流（one-piece-flow）模式，避免“半成品”。

在PP沙盘中，前期IT有很多瓶颈：

1、团队知识、资源未共享，导致无法分担彼此的工作。

2、Lead Engineer成为整个IT的最大瓶颈。

3、完成业务部门项目的工作量远大于实际可以完成的。

这时候，VP的作用非常重要，需要平衡业务部门的压力和实际IT团队的工作量（而非一味接受），对于业务部门看起来“很重要”，但对于整个公司层面ROI改变不大的项目进行取舍，say no。

而IT团队内部会使用单件流，进行持续交付，避免半成品的出现。

思考五：对工作进行合理分类。

IT的工作可以分为四大类：业务项目、IT内部项目、变更、紧急事件（issue）。

PP沙盘后期，IT团队的可承受的工作量已经足够大，瓶颈已经转移到了业务层面。这时我们发现有大量的工作量闲置，开始着手进行IT内部项目（因为不牵涉到业务部门的工作量，同时可以充分利用IT的闲置工作量）。但我们忽略了“紧急事件”对我们的持续影响，以至于最终市值和股价受到了一定的影响。

因此，在这一方面，更类似于时间管理。

我们需要在不同阶段，权衡时间、精力同各项工作之间的关系，以更全局的视野制定策略，排定优先级，进行任务分工和团队协作。

当下可能会有短暂的损失，但从辩证的角度来看，这种损失可能是值得的，应为它会在长远期带来更多的收益和回报。

通过这次的培训，对于DevOps文化有了更清晰的认识。

很高兴结识来自于各行各业的伙伴。

感谢萧帮主、汪老师、王老师的专业授课，也感谢丛琳小姐的全程支持保障。

我们是DevOps Master。