技能和实践列表我们用于内部培训我们的开发运营人员

疯狂开发人员的开发运营：我们用于内部培训开发运营人员的技能和实践列表。

早在我们将Mad Devs注册为公司之前，我们的团队就开始应用DevOps实践。具体地说，10多年前，我在另一家公司遇到过这种方法，我在那里担任系统管理员。

当时，这个术语还不存在，但是人们，包括我自己，已经应用了还没有正式形成的规则和原则，这些规则和原则后来被称为DevOps：

事实上，所有这一切都是敏捷宣言中列出的实践的合乎逻辑的扩展，从开发人员停止为本地主机编写代码的那一刻开始。

当时由Atlassian提出的DevOps方案在今天仍然适用。从本质上说，它是产品开发和交付的现代周期，其中也包括其上市后的运营。

在很长一段时间里，产品的运营与开发和开发者是分开的。这是由一些自称为系统管理员的无人居住的邪恶生物完成的。系统管理员没有参与开发和沟通。他们从墙上的一个洞里拿到代码包，并试图在某个地方运行这个代码，大声喊着四个字母的单词。每一次尝试运行它都是痛苦的。他们不得不花几天时间盯着日志，搜索无法理解的错误，分析数据库查询，陷入困境等等。后来发现，只需要定义一个新的环境变量或向配置中添加一个新参数：只是开发人员没有警告管理员，管理员只知道产品的名称和它是用php…编写的。

回到怀旧的过去：10年前，当我开始在我的团队中做管理工作时，我没有像一个刻板的管理员那样被放在地下室里，远离其他人。相反，我在开发人员密集的地方找到了一个工作场所。这就是我开始做DevOps工程师的那一刻。同时，我了解到，尽管知识和技能很重要，但更应该优先考虑沟通和从运营岗位直接影响产品的能力。我有权反对和表达我的担忧，而开发人员能够在交付之前很久就传达或调整他们的需求。如果你的管理员试过了，他们永远不会同意在地下室坐下的！

事情很快就清楚了，当把产品的设计、开发和操作放在一起考虑时，它真的是有益的。当每个人都对产品负责，并且知道在生产环境中在哪里、如何以及推出什么时，为开发人员提供访问“生产”的权限就不再是问题了。当然，无论是Ops还是Devs都不应该在没有严重需求的情况下出现在那里，但在当时，这是一种文化冲击-开发人员登录了，但它没有关闭！当你在开发人员和操作人员之间筑起一堵墙时，这绝对是不可能的。

但是，如果DevOps是一个添加了开发阶段的敏捷开发过程，那么这些DevOps工程师是谁呢？DevOps世界的核心责任清单上有哪些？最后但并非最不重要的一点是，

团队中的这一角色可以由中层专业人员接管，而不考虑职称或职业(我们可以考虑开发人员、管理员，甚至QA人员)。DevOps存在的主要目的是填补产品持续集成、交付和运营周期中的漏洞。

在我的主观意见中，DevOps最好由有管理背景的人来领导(但不是“任何关键”的专家)。在这种情况下，该人员将处理与低级问题(如数据库升级、配置管理或任何其他可能分散开发人员注意力或惹恼开发人员的基础设施事务)相关的团队负载。我还想提出另一点来证明管理员作为DevOps的领导地位是合理的：随着产品的增长和开发，DevOps团队也开始成长和发展。这将需要更多的时间和精力，如果一个开发人员领导您的DevOps团队，这个开发人员将开始在开发中搞砸。我支持由管理员领导的团队的最后一点是，管理员的入门级较低，因此这意味着启动更快。

DevOps应该知道和能够做什么？我们已经针对DevOps工程师提出了我们自己的要求清单。免责声明：我不会在这里列出所有要点。我将总结他们应该具备的核心技能。

敏捷开发原则。这是现代开发世界中最重要的技能之一(尤其是远程技能)。这不仅包括区分看板和Scrum的能力，还包括与团队沟通、了解对客户的价值、跟踪时间以及创建可读的工作日志、站立报告和清晰文档的能力。

自动化+一切都作为代码。你应该尽快摆脱手工的“苦差事”。如今，几乎每项例行任务都有一个工具。如果您找不到现成的工具，您总是可以使用Python和bash自己编写它。例如，如果需要创建虚拟机映像，则使用打包程序。如果您配置了10台以上的主机，请继续使用Ansible。如果您在Google Cloud平台上创建Kubernetes集群，或者在Amazon上做CDN，使用Terraform可以让您的生活更轻松。从通过网络加载新的裸机服务器到将新的容器部署到现有集群，一切都应该是自动化的。您编写的代码应该是可重复的，并且是幂等的。提交必须根据跟踪器中的任务进行证明，并遵守上述要点。

云和混合架构。我们目前看到一些公司正在努力不再仅仅依赖于一家云供应商(他们有理由这样担心)。您不应该只是一种云解决方案的拥趸和传道者。服务的不同部分可以在AWS、Heroku和其他IaaS、PaaS和SaaS上运行。需要找到最有利的解决方案，能够在充足的时间内实现平台间的服务迁移。不要忘记我提到的自动化，以减少迁移的痛苦。

可扩展性和高可用性要求。重要的是要了解业务对一段时间内的停机和数据丢失等的容忍度。对于可以停机24小时而不会对业务造成严重损害的资源，确保其高可用性是没有意义的。同时，另一种资源每小时停机的成本可能比其提前一年支付的完整热备拷贝的成本更高。有了云和集装箱化，扩大规模变得容易得多。但是，基础设施和服务本身都必须准备好进行扩展(在这里，我应该提到为对象使用本地存储最常见的问题)。

监控和警报(&A)。对于回顾、预测和反应，有必要收集您的系统、应用程序和业务的所有可用指标。这支队伍必须有眼睛。没有通用的监控解决方案。每个云服务或平台都提供自己的一组可用指标和警报，但通常情况下，仅使用一种解决方案是不够的。您可以使用Librato或Datadog等外部系统，也可以在普罗米修斯之上构建自定义监控服务。一切都基于预算、时间和任务。

保安。确保安全不是DevOps工程师的核心责任。然而，基础知识是必要的。终端上的SSL、策略中的NO*、无公共或开放写入存储桶、分区加密、封闭式防火墙和安全化组、MFA等。除此之外，DevOps还应与安全部门合作，实现流程自动化并快速为服务应用新的安全策略。

如果一切似乎都配置妥当且工作正常，DevOps专家可以做些什么？让我们承认开发人员已经设置了一个环境，了解了如何运行数据库，并创建了一个自动缩放组。或者，比这更简单的是，我们假设他们已经在Heroku上启动了一个应用程序，添加了必要的插件，并且可以睡个好觉。有一些警报和指标已经就位，一切看起来都很好。

由于所有操作通常都是手动完成的，因此如果您的云供应商出现问题，不可能重现体系结构或恢复其中的一部分。

由于缺乏对资源消耗的控制，成本很高。很多东西一旦配置就可能会被丢弃，但它们仍然是付费的。通常，快速推出是优先考虑的，因此在许多情况下，没有对成本进行研究，也没有对各种报价和替代方案进行比较。没有预留实例提前购买。

部署过程没有很好地建立起来。没有一致性测试的实践。集成测试很少到位。测试是由开发人员在本地完成的，如果测试曾经运行过的话。

有一些奇怪的错误只出现在生产中，不能以任何方式在当地复制。这会影响客户对IT部门的信任，IT部门必须参与与项目产品负责人的持续斗争。

性能问题的发生没有明确的原因。这里和那里都有SPOFs，解决办法和修复需要大量时间，这会使本已缓慢的开发过程变得更加缓慢。

需要将您的服务迁移到另一个平台，并为当前体系结构的快速增长做好准备。

监测警报来得太晚，无法采取行动。团队将是最后一个知道停机问题的人。在最坏的情况下，它发生在用户和客户注意到它之后。

此列表不完整。我本可以说出更多的问题。有些问题可以在及时的对话中解决，有些需要在交付和开发过程中进行更改。要继续进行这些更改，您可能需要纯技术技能或特定平台的知识。在任何情况下，即使是熟练的DevOps专业人员在项目中的短暂参与也会对您的团队和总体开发过程产生积极影响。

另外，我要感谢奥列格·普扎诺夫，是他启发了我为我们的博客写这篇文章。

欢迎来到一个语言很重要的地方。在媒体上，聪明的声音和原创的想法占据了中心舞台-看不到广告。观看。

关注所有你关心的话题，我们将为你提供最好的故事到你的主页和收件箱。探索。

不受限制地访问媒体上最好的故事，并在您工作的同时为作家提供支持。只有5美元/月。升级换代