DevOps 到底是什么？我认为这是每个 DevOps 新手在早期都会问的问题。
如果你问 10 个人这个问题，你很可能会得到 10 个不同的答案。这积极地说明了 DevOps 的普遍性、开放性，但也说明了缺乏明确的定义或实施。这不一定是坏事，但它可能会让 DevOps 初学者感到困惑。
有些人会回答你的问题，“这是一种文化，因为它打破了障碍”或“这是 Jenkins 流水线，因为它们可以帮助你更快地交付软件。” 这些答案并不糟糕，但我的意思是，以最友好的方式来说，这些答案远非完整。 因此，它们是完全错误的。
DevOps 不是一种文化、一套工具、流程和程序，也不是关于运营和开发的学术理论。 我认为，试图用这些术语来定义 DevOps，我们会忽略 DevOps 的更大图景，因为实际上，DevOps 是所有这些以及更多。
你对 DevOps 的定义可能取决于你在组织中的级别。 这是因为不同的级别对公司的整体目标有不同的看法。 高层领导拥有 50,000 英尺的视角，团队领导拥有 20,000 英尺的视角，而工程师则处于不同的深入细节的层面。 这些是这些人运作的抽象级别； 因此，DevOps 对他们每个人来说意味着不同的事物。
抽象级别
我最近读了一本很棒的书，名为 This is Lean，作者是 Niklas Modig。 他详细介绍了“精益”的详尽定义列表如何导致对“精益”是什么的混乱理解。 Modig 将这些定义分解为他所说的“抽象级别”。 在这里，我将对 DevOps 做同样的事情，我将使用 Modig 的水果示例来解释这个概念。
一块水果
假设你在一家咖啡馆，你向咖啡师要一块水果。 你期望得到什么？ 一片还是一整个？ 特定颜色？ 一片梨和整个梨非常不同，红色和绿色苹果也是如此。 这是我们的最低抽象级别，因为我们处理的是影响个人、团队、组织或公司的具体细节，但不会超出这个范围。
就 DevOps 而言，这将类似于：“我们在 Jenkins 中编写脚本式流水线还是声明式流水线？” 它是流程和程序，是个人和团队的决策，这些决策仅影响他们的团队，甚至可能影响他们的组织。 例如，我不能期望我为 A 团队编写的流水线如果被直接拿走并放在 B 团队的存储库中就能工作。 这些团队处理的事情非常不同，因此我编写的流水线对于每个团队都非常不同。 我可能会从一个团队那里获得知识和想法，但在另一个团队中以不同的方式应用它。
一种水果
在中间抽象级别，是不同的水果。 当你向咖啡师要一块水果时，你会得到哪种水果？ 梨还是苹果，但水果的颜色和切块并不重要。
我们也可以在 DevOps 中这样做：“我们使用 Jenkins 还是 GitLab CI？” 或 “我们使用 GitHub 还是 Bitbucket？” 或 “我们使用云解决方案还是内部托管？” 这些是影响公司内整个组织，甚至可能影响整个公司（如果他们从事规定整体企业工具的业务）的决策。 虽然我为 A 团队编写的流水线不会直接适用于 B 团队，但我仍然在编写 Jenkins 声明式流水线，因为我的组织已将 Jenkins 作为我们首选的 CI/CD 工具，至少目前是这样。
一篮子水果
最后一个抽象级别是水果篮，或者说“水果就是水果”的想法。 在我们的示例中，当你向咖啡师要一块水果时，她从一个黑色的袋子里伸出手，拿出她首先触摸到的任何水果。 梨和苹果之间没有区别； 它们只是水果。
对于 DevOps，这就是“这是一种文化”的定义完美契合的地方。 一个组织可能会决定它想要在软件交付中实现更多的自动化，或者打破开发人员和运营团队之间可能存在的隔阂。 这是一套在纸面上看起来很棒的概念，但没有人定义实施细节。
应用黄金圈法则
我们仍然需要一个 DevOps 的定义，我想不出比应用 西蒙·西内克的黄金圈法则模型来描述我们的水果层次更好的方法了。 在西内克的模型中，组织以某种方式（“如何做”）为了某种目的（“为什么做”）做某事（“做什么”）。 西内克认为，“为什么”是公司最重要和最具决定性的因素。 黄金圈可以准确指出当前和潜在客户的差异化因素。 同样，为了定义 DevOps，我们需要理解“为什么”它首先是有意义的。
为什么呢？
西内克写道，阐明“为什么”如此强大，是因为它有助于其他人与公司建立情感联系，并激发忠诚度和灵感。 在 DevOps 中，这就是文化定义发挥关键作用的地方，但我们需要更多。 如果我们对“为什么”的回答是我们实施 DevOps 是为了更快地向客户交付软件，那么我们未能建立情感联系。
相反，如果“为什么”是“将客户的需求与公司所有垂直领域联系起来，以便在对客户最重要的时候优先处理对客户最有价值的工作”，那会怎么样？ 这创造了一种与客户产生共鸣的联系。 他们可以相信我们重视他们的成功，因为它意味着我们的成功。 对于员工来说，他们现在看到了他们的创新和创造力如何为我们最重视的东西（客户）而不是仅仅是我们的底线创造价值。
我们如何实现“为什么”？
当我们非常精确地定义“为什么”时，我们不会规定“如何做”和“做什么”，因为重点是激励我们的员工和同事确定我们如何交付以及交付什么。 在 DevOps 中，这完美地符合了文化的理念，但“如何做”定义了这种文化。 这可以在西内克的著作中清楚地看到，他将“为什么”的问题与公司的价值和优势联系起来。 我认为这些是描述公司文化的驱动因素。
我们如何将客户需求与公司垂直领域联系起来？
在 DevOps 之前，公司内不同的组织/团队/小组拥有不同的工作是很普遍的，而且对于大多数人来说，他们只知道自己的工作。 他们有定义他们如何以及在什么上运营的标准操作程序 (SOP)，但个人很难知道他们如何为整体做出贡献。 DevOps 打破了孤岛，团队不再由运营和开发等垂直领域组成，而是由水平领域组成。 也许这些团队专注于特定的客户或特定的软件功能。 关键是团队由运营客户需求所需的所有专业知识组成，而不是仅仅由积压工作中的工单组成。
我们如何在正确的时间交付客户需求？
在当今市场上，仅仅拥有最大的功能集、最佳的用户体验和最出色的客户服务是不够的。 这些都只是附加价值。 意思是它们增加了价值，但它们并没有促使客户选择我们而不是竞争对手。 它们不再定义我们的行业。 客户通过我们发布的时机和适用性来感知定义的价值。 我们如何满足他们的需求是通过将我们的重点放在客户身上，而不是放在某人认为会提高盈利能力的下一个项目上。 我们如何在正确的时间交付是将前者与自动化相结合，自动化可以简化我们的交付，使其具有可重复性、稳定性、安全性并且速度更快。
我们使用什么来在正确的时间交付需求？
如果做得正确，领导层已经定义了“为什么”和“如何做”，但将“做什么”留给了组织和团队。 “做什么”包括在特定情况下有意义的工具和定义的流程，但可能对整个组织甚至不同的公司都没有意义。 例如，我的团队编写声明式 Jenkins 流水线，因为我们喜欢它提供的较低的入门门槛，而无需学习 Groovy 即可管理流水线。 公司中的其他组织完全依赖脚本式流水线，因为他们的团队更擅长为 Java 虚拟机 (JVM) 开发。 无论如何，“做什么”是团队用来推动公司实现“为什么”的具体细节。
什么是 DevOps？
答案是，视情况而定。
这取决于你的角色、你应用的抽象级别，以及最重要的是，你为哪个公司、组织或团队定义 DevOps。 我认为，C 级领导应该至少在表面上了解所有的抽象级别和黄金圈法则的层次。 但要注意只定义“为什么”，也许在“如何做”中发挥作用。 激励公司的其他人员提出“如何做”和“做什么”的细节。 对于个人贡献者，在开发你的团队/组织/公司将用来使自己与竞争对手区分开来的“做什么”时，要大胆、要有创造力、打破障碍并跳出框框思考。
我相信 DevOps 是打破障碍、粉碎规范、交付质量、公司与客户的共生联系、不断改进和学习的驱动力——简而言之，是一种专业的生活方式。 我希望你在这篇文章中找到了价值，并且它能激励你继续 DevOps 之旅。 这条路漫长而永无止境，就像生活中许多有价值的旅程一样。 我希望有一天能在路上见到你。
2 条评论