既然您点击了这篇文章，您可能想知道为什么您没有从 DevOps 流程中获得您期望的质量、效率和满意度。 也许您认为其他组织比您做得更好。 如果是这样，您可能试图做其他人都在做的事情，而不是独立思考并构建一个适合您组织的 DevOps 倡议。
回归基础
花点时间思考一下您希望通过 DevOps 实现什么以及为什么。 最终，我们都希望更快地构建和开发软件。 如果我们实践任何敏捷方法（scrum、kanban、SAFe 等），那是因为我们相信它将帮助我们实现这个目标。
如何实现？ 通过不断地检查和调整。
一切都是为了更快地实现您的目标。 您和您的团队或公司为之而生的目标。 这些可能不是您在六个月、十二个月或十八个月前计划的目标。
一个强大的 DevOps 组织具有适应和自我修复的能力。 它有一些简单的规则，允许一个自我组织的系统涌现，在这个系统中，决策是为了整个组织的利益而做出的，而不需要中央权威。
为了实现规模化 DevOps，您需要一个管理策略； 您不能只关注技术实现，例如持续集成/持续交付 (CI/CD) 或 微服务。 以下八项原则指导我们在 La Poste 实现规模化 DevOps 的方法。
1. 构建特遣队，而不是团队
以最简单的形式来看，DevOps 可以被视为敏捷在交付流程中的延伸。 这是一种打破开发团队和运维团队之间壁垒的工作方式。 DevOps团队在其他团队之间找到了自己的位置，在开发和运维的壁垒之间增加了一个“DevOps 壁垒”。 相比之下，DevOps 特遣队 模糊了开发和运维之间的界限，将它们整合到一个壁垒中。 这不仅仅是将“团队”重命名为“特遣队”； 这是一种完全不同的战略方法，可以扩展您的 DevOps 实践。
将您的特遣队视为一个多能力中心。 它的目的是加入一个项目，并在所有可以加速其交付流程的事情上帮助开发和运维团队，而不仅仅是 CI/CD 的实施。
例如，技术债务可能会通过以下方式消耗您的速度
- 不采用最新的性能更新可能会降低您的产品速度，并可能导致自定义代码的变通方法。
- 不实施最新的安全更新可能需要供应商的额外支持（换句话说，就是花钱），但许多组织在发生安全漏洞之前不会处理它。 这可能会对公司造成很大的损害，而且处理损害意味着使用本可以投资于扩展业务的资源。
- 软件和工具的迁移计划可能需要 6 到 18 个月。 在迁移计划开始之前等待它们达到生命周期结束 (EOL) 会对业务产生重大影响和成本，并减慢产品团队的速度。
特遣队以其高技能和多元化的成员而闻名，他们可以在以下方面帮助其他项目和部门
- 识别缓慢的流程（例如，入职面试、在多个 sprint 期间工作的实时团队）
- 自动化缓慢的流程（例如，按需暂存环境、应用程序测试、平台测试、基础设施测试、虚拟机模板化、容器构建过程、ChatOps）
- 帮助人们提高绩效（例如，培训实验室、新员工帮手、棕色袋子午餐会、聚会）
- 确保团队可以继续并维护他们的工作
2. 创建一个自组织系统
当您观看一群鸟飞翔时，您可能会注意到没有一只鸟在协调它们的运动。 简单的规则允许一个自组织系统涌现，这有利于整个群体。
在一家符合 DevOps 标准的公司中，团队需要能够在几乎没有或没有开销的情况下彼此同步。 例如，开发团队可以与服务提供商互动，而无需与内部团队同步。 他们必须在内部实现这种无同步能力。
以下是我的三个简单规则（找到适合您组织的规则）
- 全面了解团队的可用性（例如，开发-构建-服务状态、人员计划）
- 完全访问您正在进行的工作（例如，消除电子邮件和政治，而是对所有事情使用在线看板：项目、任务、会议记录、链接、讨论）
- 一次处理一项任务，以防止上下文切换
为了遵守我的规则，我每天打开两次电子邮件应用程序。 我禁用了 Slack 通知，每小时查看一次。 所有浪费都消失了，真正的东西出现了，如果我急需帮助，人们会打电话或来到我的办公桌。 我还使用 思维导图 应用程序 FreeMind 和手机上基于 番茄工作法 的计时器应用程序来帮助我集中注意力。
您必须不断检查和调整，以便团队可以找到自己实施和处理规则的方式。 需要注意三件事
- 我相信第一次迭代不会是完美的，因为采用是缓慢的，并且伴随着迭代
- 您必须接受速度减慢，然后才能获得速度
- 帮助团队公开对其内部结构的见解是 DevOps 特遣队的一部分
3. 与敏捷教练密切合作
DevOps 是敏捷的延伸，因此您需要与敏捷教练合作。 如果您需要，请聘请一位，因为您需要一位倡导者。 您所谓的“数字化转型”取决于与他人共同构建您的愿景； 您必须达成共识，因为您并不总是拥有正确的答案。
在当今的组织中，每个人都对如何实现 DevOps 有想法。 如果他们不相信您在做正确的事情，他们会减慢整个系统的速度（有意或无意）。 人们需要理解您在做什么以及为什么这样做。 一旦达成共识，就让倡导者完成他们的工作。 这是继续取得进展所需的温和启动。
4. 培训团队软技能
我建议提供简短、高度集中且实用的软技能培训——DevOps 团队每天使用的工具，而无需成为高级用户。 以我的经验，每个人都对这种方法感到满意，并且采用率立即提高。
我培训团队的一些软技能包括
- GitLab：青铜/入门版或黄金/终极版之间有什么区别？ 我们可以添加哪些功能？
- 我们如何以及为什么签署我们的 Git 提交
- SSH
- Bash 高级用法
- Sed/Awk
- OpenSSL
5. 赋能团队
通过给予团队一些空间来提高参与度。 是的，信任必须建立起来，并且必须非常认真地对待。 明确他们职责的界限以及您希望他们实现的目标。
了解他们在这些限制范围内可以（并且将会）破坏什么。 尽管如此，让他们决定自己的“批准/不批准”。
最重要的是，当出现问题时，您知道并且可以控制中断区域，当您赋予团队权力时，这种情况更有可能发生。
6. 不确定性是您的朋友
这是一个简单的循环
- 让一小群工程师参与到真实的、最终用户的关键绩效指标 (KPI) 中
- 让他们决定如何实现这些指标
- 管理如何处理任何失败
- 重复
帮助团队进行 KPI 审查。 像商业天使与初创公司合作一样工作：对许多公司进行投标（记住这是关于规模的），控制失败，并扩展和收集成功案例。
请记住，如果不能从失败中吸取教训，失败仍然是失败； 否则，它就会变成经验。 经验是质量的驱动力。
作为一名管理者，不要关注失败。 相反，要关注无责的事后分析：我们如何防止它再次发生？ 如果可以，请参与事后分析。
7. 这不仅仅是技术实施
DevOps 是关于帮助将敏捷和精益开发原则扩展到生产环境。 这通常被视为自动化交付流程，但它的意义远不止于此。
站点可靠性工程 (SRE) 是谷歌在 DevOps 出现很久之前就引入的，它实现了 DevOps 原则。 DevOps（以及一般的敏捷）可以被看作是一种进化机制：不断失败、修复和尝试适应。
一些最佳实践（例如 CI/CD 管道）和技术架构（例如容器编排和微服务）在我们的生活中占据首要地位，因为它们在设计上倾向于解决我们从失败中恢复的速度和隐蔽性。 这在定义上既是敏捷的又是精益的。
8. 及时更新
利用您可用的许多资源。 阅读 Opensource.com，订阅 Chris Short 的 DevOps'ish 每周精选新闻通讯，并参与 DevOpsDays 或 DevOps Enterprise Summit 等活动。
结论
敏捷和 DevOps 倡导者试图帮助公司提高他们的适应性。 许多传统大型公司似乎认为 DevOps 只是炒作。 以我的经验来看，它关乎生存。
评论已关闭。