问题描述
一些咨询公司正在推广一项名为”DevOps Transformation”的服务。许多大公司在世界各地的会议和聚会上都在谈论这个主题。那么，”DevOps Transformation”究竟包括哪些内容？在可行的层面上，无论是对于成功的转型还是失败的转型，它是什么样子的？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在DevOps转型中，我参与过的项目中，DevOps是对整个软件开发生命周期的全面负责。图表中的所有实践都是DevOps的重要组成部分，它们支持和支撑着系统思维和反馈循环的放大。
然而，持续集成/持续交付（CI/CD）和DevOps之间的关键区别在于软件在生产环境中的实际运行，它能够为客户和业务提供价值。
作为参与或领导DevOps转型的顾问，我首先要考虑以下几个方面：
– 文化：正如Dave所指出的，持续实验和学习的文化对于任何转型的成功都至关重要。从DevOps的角度来看，这意味着我们如何培养一种支持所选择的DevOps模型的文化，这个模型可以是”你构建它，你运行它”，也可以更接近Google的Site Reliability Engineering实践。
– 运营模式：这是业务提供的一部分，它阐述了组织将如何提供价值，通常通过高层次地将人员、流程和工具联系在一起来阐明。如果没有运营模式，你就没有一个蓝图来指导组织采用文化所定义的实践，这反过来会导致缺乏清晰度和行为分歧。
– 高层支持：作为参与转型项目的顾问，我们经常需要对业务方式进行根本性的改变。你会惹恼一些人，有些人不会喜欢这些变化，因此从上级领导那里获得支持来推动变革是非常重要的。
一旦高层支持到位，重要的是找到你可以实际交付的东西：
1. 尽可能从小开始，理想情况下，一旦有一些了解文化的人员、一个运营模式的草图和高层管理的支持，创建一个”最小可行项目”，不要试图将DevOps引入到数千人的团队中。设定一个可以实现的目标：
– 自动创建基于产品X的基础设施。
– 在所有环境中自动交付产品X到Azure。
– 将外包商Y的支持交还给伦敦的开发团队。
– 为我们最具风险的功能创建一组测试，并在持续集成中运行它们。
2. 一旦你取得了一些成功，现在是时候将更多的团队纳入其中，并让他们开始运行。不要害怕在开始时提供”白手套支持”，以帮助他们过渡；在接下来的几周和几个月里，他们将需要大量的指导。
3. 现在你有了几个早期采用者遵循新的工作方式，你有了一些关键的质量，现在是时候向更广泛的受众宣传你正在做的工作了：
– 定期举行”展示和讲解”会议，要求早期采用者展示他们的成功。
– 提供”随时进入”的会议，让组织的其他部分探索如何加入你的团队。
– 创建专注于特定领域的”实践社区”，如持续部署、自动化测试、业务沟通、风险管理、监控和警报等。
4. 坚持不懈，通过吸纳组织的其他部分来完成转型。了解Gartner Hype Cycle和采用生命周期之间的关系。为转型计划进入”失望的低谷”做好准备，坚持目标。
对于更深入的探讨，请阅读Geoffrey A. Moore的《跨越鸿沟》。我可以写一本关于如何实施DevOps转型的书，但是等我写完的时候，可能已经没有DevOps转型的工作可做了。
参考资料：
– Culture of Continuous Experimentation and Learning
– Site Reliability Engineering
– Gartner Hype Cycle
– Adoption Lifecycle
– Crossing the Chasm