DevOps 的模糊性，以及其深度和广度，常常让早期采用者感到困惑。当人们接受 DevOps 的理念时，他们首先通常会问：“我该如何开始？”和“我该如何衡量成功？” 这五个最佳实践是您开始 DevOps 之旅的绝佳路线图。
1. 衡量一切
除非您可以量化结果，否则您无法确定您的努力是否真的在让事情变得更好。我的功能是否更快地交付给客户？ 逃逸到客户的缺陷是否更少？ 我们是否能更快地响应并从故障中恢复？
在您进行任何更改之前，请考虑您对 DevOps 转型有何种结果 期望 。当您深入 DevOps 之旅时，您将享受到关于您服务各个方面的丰富近实时报告。 但请考虑从以下两个指标开始
- 上市时间衡量端到端，通常是面向客户的业务体验。它通常从正式构思一个功能开始，到客户可以在生产环境中消费该功能结束。 上市时间主要不是工程团队的指标； 更重要的是，它显示了您的企业在将有价值的 新功能推向市场方面的完整端到端效率，并隔离了系统级改进的机会。
- 周期时间衡量工程团队流程。 一旦开始开发新功能，它何时可以在生产环境中可用？ 这个指标对于理解工程团队的效率以及隔离团队层面改进的机会非常有用。
2. 启动您的流程
DevOps 的成功需要组织建立一个常规（且有望有效）的流程并不断改进。 它不必一开始就有效，但它必须是一个常规流程。 通常，它是敏捷方法论的某种形式，例如 Scrum 或 Scrumban； 有时它是精益衍生方法。 无论您选择哪种方式，都要选择一个正式的流程，开始使用它，并掌握基本知识。
定期的检查和适应行为是您 DevOps 成功的关键。 充分利用利益相关者演示、团队回顾和每日站会等机会，找到改进流程的机会。
您 DevOps 的许多成功都取决于人们有效地协同工作。 团队中的人员需要从一个共同的流程中工作，并且他们有权改进该流程。 他们还需要定期有机会与流程中上游和下游的其他利益相关者分享他们正在学习的内容。
良好的流程纪律将帮助您的组织以随着成功积累而来的高速率来消化 DevOps 的其他好处。
虽然更注重开发的团队通常会成功采用 Scrum 等流程，但以运营为中心的团队（或其他更受中断驱动的团队）可能会选择承诺期限更短的流程，例如 Kanban。
3. 可视化您的端到端工作流程
能够看到在任何给定时间谁在处理您服务的哪个部分，这具有巨大的力量。 可视化您的工作流程将帮助人们知道他们接下来需要做什么，有多少工作正在进行中，以及流程中的瓶颈在哪里。
在您看到并量化在制品之前，您无法有效地限制在制品。 同样，在您清楚地看到瓶颈之前，您也无法有效地消除瓶颈。
可视化整个工作流程将帮助组织各个部门的人员理解他们的工作如何为整体的成功做出贡献。 它可以促进跨组织边界的关系建立，以帮助您的团队更有效地朝着共同的成功感协作。
4. 一切皆持续
DevOps 承诺提供令人眼花缭乱的引人注目的自动化。 但罗马不是一天建成的。 您可以首先关注的领域之一是持续集成 (CI)。 但不要止步于此； 您会希望快速跟进持续交付 (CD)，并最终实现持续部署。
您的 CD 管道是您将各种自动化质量测试注入到您的流程中的机会。 一旦提交新代码，您的 CD 管道就应该对代码和成功构建的工件运行一系列测试。 从这个挑战的最后出来的工件是沿着您的流程前进的工件，直到最终在生产环境中被客户看到。
另一个没有得到足够关注的“持续”是持续改进。 这很简单，就像每天留出一些时间来问问您的同事：“我们今天可以做哪些小事来改进我们的工作方式？” 这些微小的日常变化随着时间的推移会累积成更深远的结果。 您会惊喜地发现！ 但这也让人们一直在思考如何改进事物。
5. Gherkin 化
在您的组织内促进更有效的沟通对于培养在成功的 DevOps 之旅中普遍存在的系统思维至关重要。 帮助实现这一目标的一种方法是在业务部门和工程师之间使用共享语言来表达新功能所需的验收标准。 一位优秀的产品经理可以在一天内学会 Gherkin，并开始使用它以明确、结构化的纯英语形式表达验收标准。 工程师可以使用这种 Gherkin 化的验收标准来针对标准编写验收测试，然后开发他们的功能代码，直到测试通过。 这是验收测试驱动开发 (ATDD) 的简化，它也可以帮助启动您的 DevOps 文化和工程实践。
开始您的旅程
不要因为开始您的 DevOps 实践而感到气馁。 这是一段旅程。 希望这五个想法能为您提供 可靠的入门方法。
评论已关闭。