您真的是“ DevOps”吗？
您已经花费了数年时间经历了惊人的转变。 您声称自己现在正式是“ DevOps”。 但是，现在呢？ 您的客户并不真正在意您是否是DevOps商店/工厂； 他们关心从该商店/工厂制造的产品如何为他们的生活增值。 常识性的东西，对不对？ 好吧，不幸的是，没有。 对于有多少人仍然还没有真正了解DevOps的精神，您会感到惊讶。 您经常会听到类似的信息：
我们是一个由开发人员组成的团队来进行操作-我们是DevOps！
- 我们是一个不断部署到生产环境的开发团队-我们是DevOps！
- 我们是Ops和Dev彼此相爱的团队-我们是DevOps！
- 我们是一个开发团队，没有质量检查支持； 我们负责手动和自动测试（单元，功能，性能，集成等），我们是DevOps！
我们是一个进行软件开发的运营工程师团队-我们是DevOps！
听起来有点熟？ 尽管以上所有内容都不是虚假的说法， 但是它们并不能完整地描述DevOps的真正含义 。 当我听到这件事时，我想到的第一件事是：“嗯，这一切很棒，但是现在呢？ 这是为谁干的？ 所有这些对您的文化，流程和工具的更改适用于谁？ 您的客户适合哪方面？ 所有这些变化如何影响您的客户？ 最重要的是，您对客户有什么了解？”
以客户为中心的软件工程师-“ DevOps”难题的缺失部分
大多数人没有意识到软件工程不仅仅是使用TDD编写干净，高质量的代码，而且测试覆盖率接近100％，因此您可以制作CD。 它不只是从整体式服务转移到微服务，将应用程序容器化，使用Kubernetes编排Docker容器，或转移到无服务器架构（还有所有光鲜的东西）。
通常不被谈论的部分是所有这些技术上的卓越成就如何改善客户的生活。 以客户为中心的软件工程师参与其中。 它们表现出以下特征和行为：
- 他们是企业家。 他们坚持不懈地致力于通过其构建的产品和所提供的服务来改善其客户（内部和外部）的生活。
- 他们不会沉迷于漫不经心的任务。 他们正念并具有自我意识（始终牢记客户）。 他们有内心的平静。 他们天生就是由任务驱动的，并且在所做的每件事中都能找到意义，甚至是平凡的工作。 他们都是关于他们要解决的问题。
- 他们不害怕 承认自己的失败 ; 他们总是从错误中学习。 他们采取措施-无需要求-防止缺陷再次出现在生产中。
- 他们不害怕获得产品的所有权并进行操作； 他们不惧怕他们编写的代码； 他们不会回避学习新技能，而是一直在寻求构建新工具以更好地了解客户如何体验他们所构建的产品。
- 他们努力快速获得客户反馈，并以迭代方式使用它来不断改进产品。 他们喜欢与客户保持亲密关系。 他们强烈反对使他们与客户保持距离的任何流程或变更； 他们 不喜欢没有增加价值的官僚机构。
这种以客户为中心的心态以及随之而来的行为对于真正的DevOps转型至关重要 。 客户至上； DevOps紧随其后。 DevOps是达到目的的一种手段。 本身不是目的。 在我的职业生涯中，我很幸运与这样的工程师一起工作。 这是真正的快乐。 您从他们那里学到了很多。
DevOps模式和反模式-从客户的角度来看。
这是谈论一些关于可靠性和速度的误解的好方法。 并重点介绍一些DevOps趋势/模式和反模式。 其中大多数是我从运营一些世界上最受欢迎的网站和游戏中收集到的见解。
＃1：正常运行时间被高估
客户不在乎五分之九的可靠性。 他们关心的是五点九的客户服务。
不久前，我在推特上发布了此消息。 我忍不住谈论人们如何盲目地认为他们-和他们的客户-需要/期望极高的可用性/正常运行时间； 像五九分钟的正常运行时间（相当于每年5分钟的停机时间），而没有考虑到到达那里实际需要的时间或客户的真正需求。
客户之所以不期望或不关心其极高的可靠性是有原因的：大多数用于通过Internet访问服务或产品的设备本身都不具备5倍的可用性。 我的意思是，您在家中多久遇到一次ISP问题？ 您的路由器？ 你的wifi？ 您的细胞载体？ 您的智能手机？ 很多吧？ 考虑到这一事实，试图使您的产品比其他任何设备都更有用。 作为客户和用户，我们几乎习惯了几乎所有使用过的停机时间。 我们只是与它一起生活（或已经学会与它一起生活）。
当然，过多的停机时间是不好的。 要知道什么是正确的水平，您需要真正了解您对风险的承受能力； 您的客户真正想要的是什么？ 他们如何应对停机时间； 等等。您需要正确的工具来获得准确，快速的反馈。 根据这些数据，您需要确定可以可靠地权衡新功能以确保可靠性的程度。 一个很好的方法是建立预算：错误预算； 正常运行时间预算。 公式很简单：走过去吗？ 慢一点。 下？ 船……船……船。
这些天的现实是，您无需做太多事情就可以达到九位数的可用性。 并且，也许，这就是您要做的（至少在最初是这样）。随着分布式系统的民主化以及诸如Kubernetes（K8）之类的容器编排系统的采用不断增加，除其他事项外，它还为您提供了自动修复之类的功能。 ，自动扩展，负载平衡，服务发现等功能，本来就可以使用-您可以立即获得一些“便利”。 此后的每个“九”都不便宜（肯定不是免费的；可能会变得非常昂贵）。
您确实需要认真研究并尝试真正了解可靠性和性能是否是您的战略差异因素，并做出正确的战略选择。 请记住，有时候，太多的正常运行时间（是的，您没听错）实际上会对您不利。
最后，在这个主题上， 正常运行时间是每个人的责任； 不只是Ops’ 。 事件/中断管理也是如此； 验尸也是如此。 如果您是运维工程师，并询问产品他们关心什么，并且得到“确保产品始终可用”的答案，则您有责任问为什么； 询问为什么他们需要您的产品“一直”保持增长； 问，“全部”是什么意思； 要求一个号码。 将操作区划为正常运行时间的唯一所有者是如此错误。
＃2：速度过高； 客户反馈被低估了。
您的客户不在乎您每天发货多少次； 他们关心您能多快聆听并从反馈中学习
像正常运行时间一样，大多数人都认为，如果他们快速发布周期，他们的工作就完成了。 您一天要多次发货； 您已将部署时间从几天减少到几个小时； 您已将发布频率从几周增加到几天甚至几小时。 太好了 我并不是说这很糟糕。 关键是快速发布周期再次成为赌注（这些天）。 问题是，大多数人并没有把重点放在发布某些东西之后会发生什么。 客户的反应如何？ 有什么反馈？ 您是否迅速收到反馈？ 直？ 您是否具有正确测量反馈的正确工具？ 您根据反馈采取了哪些行动？ 换句话说， 您学到了什么？
如您所知，大多数创业公司都失败了。 客户从未使用过大多数功能； 绝不采用大多数工具。 这不是因为技术，而是因为他们无法实现快速的反馈周期。 他们没有从过去的错误和失败中学习。 瞧，仅仅盲目地运送货物是不够的。 重要的是，在发货后，您还应该专注于所学内容。
我们常常忘记为什么我们还要多次部署产品才能提供产品及其真正的价值。 我们常常忘记为什么我们甚至进行了耗时数月/数年才能完成的大规模计划，因此我们能够不断地部署到生产环境。 如果您（作为工程师）对了解和了解您的变更如何影响客户不感兴趣，那么该变更是否在一天，一个月或一年（即您提交后）中生效并不重要。
作为软件开发人员，您有责任好奇和好奇，并迅速获得有关您交付生产的功能或更改的反馈。 速度（您的运送速度）不够。 快速反馈环路至关重要。 您是否想知道几个月前所做的重要更改对客户参与度产生了什么样的影响？ 你在乎吗？ 你觉得这些东西吗？
重要的是不要构建客户不想要的东西。 快速反馈循环是确保结果的有效方法。 确保尽快使您的假设无效（“快速失败”）。
＃3：运营民主化-为什么每个人都是Ops和每个人都是Dev
如果您想发展以客户为中心的思维方式，那么这种文化转变（每个人都是行动主义者；每个人都是开发者）至关重要。 我们所看到的大多数趋势都是需要快速直接从客户那里获得反馈的直接结果，因此工程师可以快速迭代该反馈并交付更好的产品。 它们也是尝试模仿的好趋势，因此您可以使工程师更接近您的客户。
运营商正在逐步发展
基本上，随着云计算，（Docker）容器，不可变部署，Kubernetes，无服务器，Istio，Envoy（用于服务网格），微服务以及分布式系统的普遍民主化的兴起，基础架构空间正在经历重大变革，并且（模式转变。 就创造价值和创新而言，业务逻辑本身不再是与众不同的了。
考虑到这一转变，构建应用程序和业务逻辑的核心软件团队确实需要整个生态系统才能成功并能够快速进行大规模创新。 因此，更重要的是，他们还必须学习如何大规模操作其复杂的分布式系统。 否则，它们迟早会变得无关紧要 。 如果您是开发团队，并且在调试复杂的生产缺陷时每次都要负责分析分布式跟踪或运行数据包捕获而不得不召集另一个团队，那么该策略不会使您放慢脚步，它还会显着降低您的工作效率。增加您的TTR，从而使客户沮丧并最终损害您的业务。
对于所有抽象（大多数都是泄漏的），运行这些分布式应用程序的操作复杂性也在成比例地增加（尤其是在规模上）。 通常，这是运维专家介入并增加价值的地方（直到那时才需要他们）。 他们使规模经济发挥作用。 他们真正地在往上走。 他们必须; 否则，它们迟早会变得无关紧要。 鉴于需要使运营民主化，这种趋势是不可避免的。
作为一个职业/职业，Ops在过去的十年中已经走了很长一段路：从机架/堆叠服务器（上世纪90年代后期）到调整内核，再到运行数据包跟踪再到配置管理。 如今，运营工程师专注于构建基础架构，平台和容器编排。 他们专注于建立可观察性堆栈。 有些还专注于如何构建，测试，部署，配置应用程序（测试基础架构和框架）。 有些更侧重于中间件和边缘/入口。 一些专注于网络编排。 一些提供数据库即服务。 清单继续。
开发人员正在向栈底移动
先前趋势的推论。 没有人真正地尽早雇用操作人员（至少直到系列B或C才如此）； 您只是不需要它们，因为作为一家企业，您只需要专业知识即可大规模解决运营问题（可靠性，性能，CD等）。 您的软件开发人员（着眼于Ops）会执行大多数初始扩展，并使产品更易于操作。 轻松访问按需，可扩展，可计费的计算云； 随着容器编排系统的兴起，分布式系统的民主化以及隐藏底层系统复杂性的其他抽象概念， 不难使用蛮力将规模扩展到数千万（如果不是几百万）的用户货架解决方案 。 实际上，（在此阶段的早期）雇用操作人员可能只是分散注意力和自我困扰的问题。
这种趋势是真实的，并且不仅在较小的公司中发生，而且在较大的公司中也发生。 实际上，在拥有十亿用户的Yahoo上，我是2015年以“ DevOps”模型（您编写，拥有/运行）启动Yahoo的Daily Fantasy的主要推动力。 这与传统上大规模操作软件的方式大相径庭。 该模型很简单：开发团队几乎负责开发生命周期的所有方面：从设计到编写代码，再到编写测试，再经过多个架构高级技术委员会的讨论，再到偏执狂的安全审查。 他们还负责测试和部署他们编写的代码（使用CD）。 最后，对其进行操作并进行缩放。 因此，诸如监视，通话，容量，验尸等之类的东西。基本上，它们是他们自己的操作。
另一方面，ops团队通过文档等领域帮助产品发布； 了解DNS，CDN，基础架构配置，监视，负载平衡等内容。 同样，在理解复杂的分布式系统中所有组件如何互连的过程中。 通过编写剧本，一天如何多次以连续方式部署软件，如何回滚等。但是在那之后，运维团队通常是放手一搏的。 他们仍然定期提供咨询和专家服务，并且是跟踪，监视，呼叫，容量，基础结构等方面的首选POC，但这几乎是安排或合同的范围。
这种模式的优点在于，它鼓励所有权，使人们负责并带来了巨大的积极成果。 最重要的是，它使工程师更接近他们的客户：使软件工程师更接近外部客户/用户； 使运营工程师更接近内部客户（即开发人员）。
该团队的工程师真的很在乎客户。 仅举一个例子，曾经有一个警报，当一个未成年顾客试图注册以玩日常幻想时，它会发出警报。 立即，触发警报（HTTP 4XX），该警报直接进入待命开发人员，该开发人员立即响应并验证系统是否已完成应做的工作（即，不允许该人注册），然后创建票证采取后续行动，使警报更具可操作性（如果警报无法实施，则无需在凌晨3点将某人叫醒）并重新上床睡觉。 太好了吧？ 没有比这更好的了吗？ 实际上，我在几次会议上都在谈论这种转变，并获得了很好的反馈。
＃4：DevOps是赌注
我认为DevOps不再是战略优势。 如今，DevOps成了赌注。 现在已经有一段时间了。 自2007年或更早（十多年前）以来，许多企业一直在进行CI / CD（“ DevOps”的很大一部分）之类的工作。 如果您仍然处于落后状态，那么是时候进行一些认真的追赶，因此您可以专注于更大，更好的问题。
战略差异因素将是您对客户（内部和外部）的痴迷程度。 这种痴迷意味着，作为一名工程师，您将专注于对客户最重要的事情。 这种思维定势将引导您开发技能和工具，以找到创新的方式来快速从客户那里获得反馈，并了解您可以从中学到的知识（快速）。 最终，您将成为一名全面的工程师和一名企业家。 一个人，不仅为编写高质量的干净代码感到自豪，而且还深深地爱上了他/她的客户。
DevOps反模式
没有列出一些反模式就无法结束。 当我听到有人向他们张嘴时，它使我发疯。
“我希望我的软件开发人员专注于编写功能； 我不希望他们做底层工作，例如响应警报，运行事件等。让我在两者之间插入三层。 这些层将屏蔽所有生产反馈。 他们将阻止开发人员在凌晨3点醒来”
- “我希望我的软件开发人员能够提高工作效率； 我不希望他们从事诸如编写测试之类的事情，这些事情会延迟我的发布。 我希望他们专注于编写业务逻辑和交付功能。 让我雇用一个团队，稍后再去增加测试范围。 让我雇用一个团队来测试每个版本的细节。 谁将成为每个版本的手动门”
- “我不想让软件开发人员专注于失败的测试，从而浪费他们的时间。 我不希望他们处理失败的部署。 哎呀，我根本不希望他们处理部署。 让我雇用一个团队来进行构建，测试，部署，回滚等”
- “我们能否让该团队为我们处理较低级别的例行任务？ 因此，我们可以专注于重要的事情。”
- “我不希望我的软件开发人员与客户打交道，也不希望他们参加用户反馈会议。 那是产品的责任。 冲刺计划已完成； 他们有足够的盘子”。
“我不希望我的软件开发人员不经过三层官僚机构就交付任何东西（甚至进行实验）。”
如果您遇到这样的反模式（大多数会使开发人员远离客户，并导致较长的反馈循环），您就会知道该怎么做。 不过，诚实面对自己很重要； 无私 做一些思考，然后做您认为正确的事情。
在您的企业内部建立企业家的旅途中祝您好运！
希望听到您的反馈和想法！
