在我的整个职业生涯中，我已经提出了一些意见。由于多年的经验，有些轮胎磨损特别深。我试图弄清楚它们之间的共同点，那就是生产中的代码是唯一重要的代码。分期无关紧要，笔记本电脑上的代码无关紧要，QA无关紧要，只有生产才重要。其他一切都是债务。
这个观点可能来自运营和产品开发之间的多年经验。我坚信团队应该进行优化，以尽可能快地将代码投入生产并响应生产中的事件。
这个想法及其所暗示的许多实践可能是反直觉的或有争议的，因此我想进一步研究它们。以下是我认为是正确的一组实践和原则，这是我的基本信念，即在生产中使用代码是唯一重要的代码。
工程师是他们编写的代码的主题专家，并应负责在生产中进行操作。在这种情况下，“操作”是指部署，检测和监视代码，以及帮助解决与该代码有关或影响该代码的事件。操作代码的责任与激励措施保持一致，它鼓励工程师编写易于观察和调试的代码，并将其与客户真正关心的内容联系起来。它鼓励他们对自己的代码如何执行生产感到好奇。重要的是，工程师应随时待命，因为他们的代码会立即产生积极的反馈循环，并使他们更容易知道他们编写生产就绪代码的努力是否有回报。我已经听到人们抱怨可以待命的可能性，所以我只想问一下：如果您不待命，您的代码是谁？
如果您目前不希望自己的代码，但希望成为您的代码，并且可以帮助您影响此决定，则可以做一些事情。为负责特定服务或代码部分的每组工程师设置PagerDuty（或类似）时间表。一个好的时间表是有6-8名工程师。有很多变化，但是一个典型的模板是轮换一周，您将在第二轮接到您一个电话，然后在一周内拨打一次。配置警报是一个单独的主题，可能值得拥有自己的博客文章完全，但要专注于影响客户的事情（请参阅：基于症状的警报），并记住您最终对警报的响应方式负责，这意味着您可以更改警报。
我建议您观看有关配置警报的主题的两个话题：Liz Fong-Jones谈论“培养卓越生产中的SLO”，Aditya Mukerjee在“警告：此话题包含了加州减少警报疲劳。
如果可以避免构建某些东西，则应该这样做。代码是解决无法解决业务核心问题的最昂贵的方法。对于大多数中小型公司，都有开源或更好的托管解决方案来解决各种常见问题。我的意思是诸如gitrepository托管（Github，Gitlab，Bitbucket等），可观察性工具（Honeycomb，Lightstep等），托管数据库（Amazon RDS，Confluent Kafka等），警报（PagerDuty，OpsGenie等）以及整个主机之类的东西。其他商品技术。这甚至适用于您的基础架构-如果您可以提供帮助，请不要滚动自己的Kubernetes集群（旁注：您是否甚至需要使用Kubernetes？），如果可以使用Amazon ELB或ALB，也不要滚动自己的负载均衡器。
不幸的是，NIH综合征非常真实，因此一些公司被严重烧毁。我已经看到，在市场上存在更好，经过更多战役考验的替代品时，团队可以节省大量时间和金钱来重新设计消防组件。那些相同的团队几乎总是要花费数年的时间来应对由此产生的技术债务。如果您在这样的团队中，并且有影响变更的意愿和能力，请开始逐个撤消这些决定。将您的数据库迁移到托管提供程序，将特征标记系统迁移到SaaS工具（即，LaunchDarkly）。一直保持下去，直到您自己维护的唯一软件就是为客户带来价值的软件。您将会获得更多，更好的回报。
部署应该是频繁而平淡的活动。工程师应该能够以最少的手动步骤进行部署，并且应该很容易看到部署是否成功（这需要对您的代码进行可观察性测试，上面已介绍了此代码），并且如果不成功，则应该很容易回滚部署。不好频繁部署意味着部署较小，而较小的部署通常更容易，更快和更安全。
许多团队会实施禁止部署的阶段-可以将其称为代码冻结，或部署诸如“周五不要部署”之类的策略。如果没有这样的停工期，可能会导致大量变更，从而增加了某些事情的整体风险会非常错误。
如果您所在的团队担心部署，则将一定比例的工程时间用于改善部署管道，直到消除恐惧。在最近与我合作的团队中，我们能够将部署时间从3小时缩短到30分钟，从而极大地提高了团队对部署过程的信心。这样做的自然副作用是工程师开始更频繁地部署，而不是等待更改堆积如山，足以保证“发布”（这是部署的代名词）。
《加速》一书已经引起了很多关注。如果您还没有阅读过，我会推荐它。它背后的团队还会发布DevOpsreports状态，其中包含了有关该行业中各个公司的详细研究信息。本书着重介绍的四个关键指标中的两个与此直接相关的因素（DeployFrequency，Change Lead Time）并非偶然。运输是您公司的心跳。
使用系统的人是最了解系统的人。这适用于我们所有人都在其中工作的社会技术系统的任何部分。在软件系统的情况下，每天进行部署并要求关键服务的工程师都了解他们所从事的风险水平。Asad的趋势是，在某些过渡时期，经理往往会高估其团队的进度。等。管理链越高，这种高估的趋势就越大。发生故障时进行部署并进行分页的工程师知道尸体被埋在哪里，他们知道什么是最需要工作的。因此，他们应该是负责技术工作优先级的主要参与者。
该原则的另一种体现适用于平台或服务团队。如果您负责构建在组织内使用的某些共享组件（即消息系统，ci / cd基础结构，共享库或服务），那么您会发现一个不舒服的真相：人民在很多情况下，使用您的作品的人比您了解的更多。他们隐含地了解它如何为客户提供服务，并且他们知道要使其正常工作必须跳过哪些扭曲或陷阱。听他们提供有关如何改善服务和工具的用户体验的线索。
许多团队都有手动的质量检查步骤，需要在部署之前执行。我想，这个想法是让某人运行自动化或手动测试，以验证准备好发布一组更改。这听起来像一个安慰的想法-让一个人（或一个人的团队）在释放之前“验证”一个释放--但它成为几种错误假设的受害者，并造成一些错位，弊大于利。
首先，如果在部署完成之前需要做一些手工工作，这会造成瓶颈a-如果您使部署变得容易并且经常进行小的更改，则没有质量检查团队能够继续对每个部署进行测试，这将不可避免地阻止团队部署。不好如果您有手动测试，请使其自动化并将其构建到您的CIpipeline中（如果它们确实带来了价值）。
其次，进行质量检查的团队通常缺乏背景，并承受时间压力。他们最终可能会测试“效果”而不是“意图”。例如，我见过质量检查小组进行时间测试，即当UI中发生某些事情时，数据库中也发生了相关的事情。当工程师重构该UIcomponent并更改基础数据模型时会发生什么？功能正常，但测试失败。由于涉及两个团队，因此需要协调和时间来解决。类似地，我已经看到QA团队由于在CDN层上引入缓存时的测试失败而阻止了部署-ever用户可能永远不会注意到活动订阅源上5秒钟的TTL，但这可能会破坏QA测试，从而导致产品与QA之间不必要的冲突工程师。
幸运的是，解决这一问题很容易。与其让专门的QA团队工作以创建在虚拟QA环境中运行的手动和自动测试用例，不如将其重新分配为在生产中进行连续测试。预期。质量保证团队也很容易领导Chaos Engineering计划，在计划中故意注入故障。质量检查工程师还可以致力于使CI / CD管道更加可靠，从而使部署不再是一场噩梦。
多亏了丹·麦金莱（Dan McKinley），在可能的情况下始终努力寻找无聊的技术。系统本质上是不可预测的，并且当您将这些东西丢到一边时，您希望获得广泛的专业知识。您还需要执行一些日常操作（部署，数据库迁移等），并且拥有广泛使用并经过测试的工具非常好。当我想到这种信念时，我最常想到数据库。 MySQL是一个有许多怪癖的数据库，但是它已被广泛使用，因此您仍然应该在大多数时间仍然使用它。
很少有组织具有调试独特问题的带宽。您不需要独特的问题，尤其是在执行常规操作时，例如在磁盘上存储字节，在集群中选择新的领导者，垃圾收集对象，查询时间序列数据等。拥有独特的问题将杀死中小型团队。它可以减轻您的创造力，更好地为希望为您的软件付款的客户创造价值。明智地使用您的创新代币！
使用无聊的技术意味着您可以依靠庞大的用户社区。随心所欲，但是很少有人遇到其他PHP问题。如今，对于足够广泛使用的Ruby on Rails版本而言，情况可能是如此。我经常说我喜欢参加第三次技术采用。第一组是出血边缘组织。第二类是觉得自己会冒险的人。让这两个小组摆在您面前，遇到所有大问题，然后您就可以从他们来之不易的经验中受益。
关于这一点，我没有太多要说的，但是我们都在编写YAML和JSON而不是XML，并且都使用HTTP而不是CORBA，RMI，DCOM，XPCOM等。对？本着同样的精神，我宁愿每天调试LAMP堆栈中的问题，也不愿使用微服务架构。
微服务的快速侧边栏：与技术的众多趋势一样，它们通常被视为万灵药。让我清楚一点：微服务设计得很好，可以解决某些特定问题，并且与大多数解决复杂问题的方法一样，需要进行一些权衡。如果您朝着这个方向前进，我确实对应该如何做有意见，但是我也认为您应该在可能的范围内坚持下去。
本节更直接的标题是“非生产环境废话”。分期或预拍品之类的环境真是个骗人的谎言。当您开始时，它们有点意义，但是随着您的成长，变化会更频繁地发生，并且您会感到漂移。而且，根据定义，您的非Pronovironment不会获得流量，这使它们从根本上有所不同。维护非Prod环境所需的工作量迅速增加。由于客户不会直接接触非产品，因此您永远不会像对待非产品那样优先处理非产品。最终，您将争先恐后地保持冰棒棍和胶带环境的正常运行，以便您可以测试它的变化，对自己撒谎，假装它与生产过程没有任何相似之处。
避免失败是不可能的，甚至是不希望的。了解失败是不可避免的事实，并专注于您如何应对失败。这意味着要投资于不断改进的事件响应流程。每个公司和团队都没有合适的解决方案，但是您应该对出现问题时应该采取的措施有一个很好的了解，并且应该有适当的机制可以从这些情况中学习并改进流程。投资事件分析。这是一个巨大的领域，拥有许多有价值的工具和资源，可在发生（或不发生）事件时最大程度地提高投资回报率。
这是混沌工程可以提供帮助的领域。将故障注入生产可以提高人们对系统以意外方式启动行为时如何做出响应的信心。 “游戏日”可能是允许一组工程师练习各种中断情况的一种特别有效的方法。
这篇文章中概述的许多信念至少是违反直觉的，甚至没有引起争议，但我仍然坚信它们是正确的。这并不意味着我的想法无法改变，但这是不可能的。如果您强烈同意或不同意，那么我正在互联网上。我很想知道您的经历。