稳定性原则

去年，我开始写博客，称自己为“稳定思维定势”。我仍在研究这些构想，但我认为我有足够的时间和经验将其构想发展为一些基本的指导原则。

您可能想知道我是否只是在尝试对可靠性进行某种丑陋的品牌重塑，例如软件可靠性工程（SRE），但我认为情况并非如此-我看到的是不同的事物，或者至少是其中的特定子集SRE。如果您对更广泛的范围感兴趣，可以查看google对此事的见解。 Google有这本很棒的书，您可以查看有关SRE的信息。

我想了很多，如果这仅是凡人的SRE，但我认为不是。我真的认为这是另一种问题，或者至少可以肯定是另一种问题。今天，我写这篇文章是因为我想记录一下我最近的发现，也因为我今天与团队进行了回顾性练习，我保证我同意我的一些想法。
为什么从心态开始？ 去年，我认为我在把握这种新思维方式的一些良好要素方面做得很不错。此概念的一些主要元素包括：

代码/发布惯例，例如重试/回退/超时
正确的可观察性：可见性，仪表板，警报，指标
软件和基础架构自动化
测试中

除了事实，我仍然认为这些方面是有效的，而且还可以，但是我认为还有更多方面。我认为还有很多原因，在这篇文章中我将作解释，但是，不要误解我在上一篇文章中所说的所有内容仍然很重要，这更像是想法的演变，而是它们的演变。更正或替换。解释事情可能很困难。很容易理解某些东西，并利用自己的直觉来判断某件事是错误的。有时很难将其表达给团队中的其他成员并且清晰明了。确切说出他们应该做什么，需要停止做什么-换句话说，特定的行为和做法，可能变得更加困难。工程意味着处理各种问题，解决方案和平台。话虽这么说，当您进行可观察性或在处理Cassandra备份时或在进行内存数据库时，稳定性是不同的。但是，我确实相信核心原则是相同的，这就是我今天试图抓住和分享的内容。

这不是一个过程，但是您能轻松做到吗？

稳定并不意味着冻结。老行动主义者通常会考虑是否“控制”环境并且不放太多东西是安全的。这从来都不是正确的，而且这不适用于企业今天需要运营的当前创新水平。恕我直言，稳定不需要更多的过程，实际上，稳定需要更多的纪律。您可以按照要求执行流程，并且可以检查自己是否在做。合规性可能对安全性很好，但是只要您有开发人员或具有开发背景的人员，情况可能并非如此。因此，您可以向人们反馈他们的解决方案需要更加“稳定”，但这意味着什么？ …更重要的是他们如何做到这一点？他们开始做什么？他们需要停止做什么？这需要向其他人解释，另外一些人更容易得到它，而另一些人则让我停下来想一想更直接和清楚的事情。这就是为什么我尝试提出其中一些原则的原因。因此，这些原理背后的思想是使人们更容易理解稳定性的含义，从而对行为和实践进行更改以对其进行存档。

老年人对不同的人意味着不同的事情

一家公司的高级工程师可能意味着该人员无需任何沟通或支持即可提供高质量的工作。对于像我公司这样的其他公司，这意味着您既可以单独交付高质量的工作，又可以学到任何东西，也可以教别人做。我和其他公司一样，其他定义还有高级工程师的意思，这很好。所以您可能想知道为什么我要提出这个问题。原因是人们有不同的背景，并告诉我您如何衡量某人，并且您将有某种行为作为回报。这意味着您可能没有它，但可能不是因为您缺乏技能，而是因为您的公司不关心或不需要关心这些事情。换句话说，我确实相信人们，而且我确实相信人们可以学习和提高，所以这不是黑白的。一点都不！精益是敏捷的根源之一，也是DevOps的根源之一。精益教育确实对正确的“愿景”和赋予人们权力深信不疑。这与赋予权力有关，使人们能够交付更多的“高质量的工作”，质量意味着稳定。

阿斯加德不是一个地方

抱歉，如果您没有看过上一部雷神电影，但他们说电影结尾处的“阿斯加德不是一个地方”，实际上无论是什么人，都是一艘船或一块土地。这就是我对稳定性的看法，它并不是由确切的规则（也称为过程）固定的。的确如此，以我的团队为例，生产就是我们的工作。我们在具有多个帐户的AWS上运行软件，某些生产表示在PROD帐户上运行的软件，有时表示在SHARED-Infrastructure帐户上运行的软件，有时表示在TEST帐户上运行的软件。稳定性应该是一种心态，无论您做什么，无论您是为我的项目使用Cassandra（真相的来源）还是诸如依赖项的报告工具之类的东西，都没有关系。当您加入CORE团队时，有些人取决于您的工作-您所做的一切都是Asgard-您所做的一切都是生产，因此所有工作都需要保持稳定。

这很容易理解，而且很难付诸实践，因为有时即使您没有更改任何一行代码，事情也可能停止工作。我确信每个人都对Spectre和Meltdown漏洞很熟悉，它们是一个很好的例子。还有另一个很棒的示例，那就是Gradle怎么从来没有第三方依赖性下载一些额外的jar并炸毁服务器启动程序？我去过那儿。

稳定性原则

好的，现在这是我的稳定指导原则：

隔离
测验
可观察性
一直在工作
配置管理
主动性
巴西人的“ Skol”原则

隔离：隔离是关键。您需要在DevOps工程或软件工程与生产之间进行适当的隔离。因此，如果您的解决方案有詹金斯的工作。您需要有2个Jenkins工作-一个用于开发，另一个用于生产。仅隔离“代码”或服务器机器是不够的。孤立性还有很多，例如，我们在Jenkins中确实使用了Slave，如果在同一个slave上有很多作业，您将排队，并且由于“ Jenkins”是您“生产”解决方案的一部分，因此开发错误可能会影响生产。解决方案或有分开的奴隶。

测试：如果您无法做到或价格太贵，则可以实现出色的自动化，至少您应该了解您的CORE功能，并在PR后重新测试所有这些功能-这会使您速度变慢，但是，会使您更稳定。但是，如果可以进行自动化始终是个好主意，则DevOps Engineering归档中的某些内容根本无法进行测试，例如CollectD，或者由于大量的远程和分布式异步工作，因此测试工作仅仅是实例。

可观察性 ：那么您需要知道您是否还好。因此，您需要掌握关键指标，基本仪表板和良好警报。这是基本的，我不需要对此做太多解释。在我当前的项目中，我不做任何面向客户的工作，而我的团队所做的大部分事情都是为了支持其他团队，因此很容易陷入可能需要一段时间才能发现问题的情况。因此，对于我的团队来说，黄金法则是可以观察到所有可能失败的事物，并且至少在闲聊中有一些警报或消息。

始终有效 ：所有巴西人都知道“显而易见的事物被视线隐藏了”这一说法，因此这是稳定思维定势的核心假设。您需要内部化该软件的想法-无论您做什么，都必须始终运行。解决方案中的所有要素和步骤对平等至关重要。因此，如果您的解决方案具有Java编码，Ansible角色，Jenkins作业和Web UI。所有这些元素都需要一直工作，您不能只关心Java部分。稳定性是全有或全无。

配置管理 ：坚如磐石的配置管理实践，例如代码版本控制，代码版本控制，GitHub上的标签，不仅使工作更安全，而且还具有轻松解决特定问题并并行开发新功能的能力。

积极主动 ：这是一种态度。如果您内化了您对所做的一切拥有完全的所有权，并且您是最后的障碍，并且如果您失败，人们将看到影响，您将采取更加谨慎的行动，并且会超出人们要求您做的事情。我们与宿舍一起工作，我们有目标，但是您不能仅仅遵循您需要的目标就得加倍小心。

巴西人的“斯科尔（Skol）”原则 ：在巴西，我们这里有比尔森啤酒，称为“斯科尔（skol）”，虽然没有什么特别之处，但是有一台电视，谈论着啤酒的流动非常顺畅，您喝起来很顺畅，因为啤酒有类似圆圈的形状，不是正方形。 Square意味着一件坏事，而这里的想法是您得到错误的东西，并且始终做到对。像童子军。您总是将环境留在一个更好的形状中，然后找到它。因此，无论您是谁做错了代码还是让代码无法正常工作—您都在进行开发，因此现在有责任对其进行修复。抱歉，我只是意识到如果您不是巴西人或不知道巴西人的推荐信，我的“ skol”隐喻会很烂-因此，请以童子军的规则为准。无论是否有过错，请始终让它比您发现的要好。一些文化参考文献很难解释，因为如果您是巴西人，他们的翻译质量不好，我希望您能理解😀

下一步是什么？ 我之所以谈论这个主题，是因为我在乎和充满激情，但也因为我所谈论的内容不多。别误会，Google，Twitter，Facebook，Netflix等许多公司都有大量的SRE内容，但是，我并不是在谈论规模或规模问题，而是问题的性质。我仍然在做所有事情的指导和编码。仍在学习稳定性心态以及如何开发更好，更稳定的软件。我将继续在这里发布我的发现。希望你们喜欢。照顾自己。干杯，

迭戈·帕切科