巧合是随机的，而且确实是在另一个星球上......
我想分享三个关于后端开发人员如何与管理员团队合作的成功和失败故事。
第一个故事。
网络工作室，员工数量一只手就能数过来。 今天你是布局设计师，明天你是后端人员，后天你是管理员。 一方面，你可以获得丰富的经验。 另一方面，各个领域都缺乏能力。 我还记得第一天上班，我还很青涩，老板说：“开腻子”，但我不知道那是什么。 与管理员的沟通被排除在外，因为您自己就是管理员。 让我们考虑一下这种情况的利弊。
+ 所有的权力都在你的手中。
+ 无需乞求任何人访问服务器。
+ 各个方向的快速反应时间。
+ 很好地提高技能。
+ 对产品架构有完整的了解。
——高度责任感。
— 中断生产的风险。
— 成为所有领域的优秀专家是很困难的。
不感兴趣，我们继续
第二个故事。
大公司，大项目。 有一个行政部门，有5-7名员工和几个开发小组。 当你来到这样的公司工作时，每个管理员都会认为你来这里不是为了开发产品，而是为了破坏某些东西。 签署的保密协议和面试时的选择都没有表明其他情况。 不，这个男人用他肮脏的小手来这里破坏我们的接吻表演。 所以，和这样的人你需要最起码的沟通，最起码可以贴个贴纸回应一下。 不要回答有关项目架构的问题。 建议在团队负责人提出要求之前不要授予访问权限。 当他提出要求时，他会以比他们要求的更少的特权归还。 几乎所有与此类管理员的沟通都被开发部门和管理部门之间的黑洞所吸收。 不可能及时解决问题。 但你不能亲自来 - 管理员 24/7 太忙了。 （你一直在做什么？）一些性能特征：
- 生产中的平均部署时间为 4-5 小时
- 生产中的最长部署时间 9 小时
- 对于开发人员来说，生产中的应用程序是一个黑匣子，就像生产服务器本身一样。 总共有多少个？
- 发布质量低，错误频繁
- 开发者不参与发布过程
嗯，我期待什么，当然，新人不被允许进入生产。 好吧，有了耐心，我们就开始赢得别人的信任。 但出于某种原因，管理员的事情并不那么简单。
行为 1. 管理员是不可见的。
发布当天，开发者和管理员不沟通。 管理员没有问题。 但稍后你就会明白为什么。 管理员是一个有原则的人，没有信使，没有向任何人透露他的电话号码，也没有在社交网络上的个人资料。 连他的照片都没有，你长得怎么样啊老兄？ 我们困惑地与负责经理坐了大约 15 分钟，试图与这台 Voyager 1 建立联系，然后公司电子邮件中出现一条消息，表明他已完成。 我们要通过邮件通信吗？ 为什么不？ 方便不是吗？ 好吧，好吧，让我们冷静一下。 这个过程已经在进行中，没有回头路。 再次阅读该消息。 “我完成了”。 你完成了什么？ 在哪里？ 我该去哪里找你呢？ 到这里你就明白为什么4小时释放是正常的了。 我们对开发感到震惊，但我们完成了发布。 已经没有任何想要释放的欲望了。
第二幕。不是那个版本。
下一个版本。 获得经验后，我们开始为管理员创建服务器所需的软件和库的列表，并标明某些软件和库的版本。 与往常一样，我们收到微弱的无线电信号，表明管理员已经在那里完成了某件事。 回归测试开始，这本身需要大约一个小时。 一切似乎都正常，但有一个严重的错误。 重要功能不起作用。 接下来的几个小时就是敲手鼓跳舞、在咖啡渣上算命、详细审查每一段代码。 管理员说他已经做了一切。 不法开发人员编写的应用程序无法运行，但服务器可以运行。 有什么问题想问他吗？ 一小时结束后，我们让管理员将生产服务器上的库版本发送到聊天和宾果游戏中 - 这不是我们需要的版本。 我们要求管理员安装所需的版本，但我们收到的答复是，由于操作系统包管理器中没有该版本，因此他无法执行此操作。 在这里，经理从他的记忆深处记得，另一位管理员已经通过简单地手工组装所需的版本解决了这个问题。 但不，我们不会这样做。 法规禁止。 卡尔，我们已经在这里坐了几个小时了，时间限制是多少？！ 我们再次感到震惊并以某种方式完成了发布。
第三幕，简短
紧急票据，关键功能对生产中的用户之一不起作用。 我们花了几个小时进行探索和检查。 在开发环境中，一切正常。 有一个清晰的认识，那就是查看 php-fpm 日志是个好主意。 当时项目上还没有ELK或者Prometheus这样的日志系统。 我们向管理部门开一张票，以便他们可以访问服务器上的 php-fpm 日志。 在这里你需要明白，我们请求访问是有原因的，你不记得黑洞和管理员24/7都在忙碌吗？ 如果你要求他们自己查看日志，那么这是一个“今生不会”优先的任务。 票证创建后，我们立即收到了管理部门负责人的回复：“您不应该需要访问生产日志，编写没有错误的代码。” 一个窗帘。
第四幕及以后
由于库版本不同、软件未配置、服务器负载未准备好以及其他问题，我们仍在收集生产中的数十个问题。 当然，也有代码错误，我们不会把所有的罪过都归咎于管理员，我们只会提到该项目的一个更典型的操作。 我们有相当多的后台工作人员是通过主管启动的，并且必须将一些脚本添加到 cron 中。 有时这些工人停止工作。 队列服务器上的负载以闪电般的速度增长，悲伤的用户看着旋转的加载器。 要快速修复此类工作人员，只需重新启动它们就足够了，但同样，只有管理员才能执行此操作。 这么一个基本的操作进行起来，一整天的时间就过去了。 当然，在这里，值得注意的是，不诚实的程序员应该编写工作程序，以便它们不会崩溃，但是当它们确实崩溃时，最好理解为什么，由于缺乏生产访问权，这有时是不可能的。当然，因此缺乏开发人员的日志。
变形。
在忍受了这一切很长一段时间后，我们与团队一起开始朝着对我们来说更成功的方向前进。 总结一下，我们遇到了哪些问题？
- 开发商和管理部门之间缺乏高质量的沟通
- 事实证明（！），管理员根本不了解应用程序的结构、它具有哪些依赖项以及它如何工作。
- 开发人员不了解生产环境如何工作，因此无法有效响应问题。
- 部署过程花费的时间太长。
- 版本不稳定。
我们做了什么？
对于每个版本，都会生成一个版本说明列表，其中包括需要在服务器上完成的工作列表，以便下一个版本发挥作用。 该列表包含几个部分，以及应由管理员、发布负责人和开发人员执行的工作。 开发人员获得了对所有生产服务器的非 root 访问权限，这总体上加快了开发速度，特别是解决了问题。 开发人员还了解生产如何运作、它分为哪些服务、副本的成本在哪里以及多少。 一些战斗负载变得更加清晰，这无疑影响了代码的质量。 发布过程中的交流是在其中一位即时通讯工具的聊天中进行的。 首先，我们有所有行动的日志，其次，沟通是在更紧密的环境中进行的。 拥有行动历史记录不止一次让新员工能够更快地解决问题。 这是一个悖论，但这通常对管理员本身有帮助。 我不敢肯定地说，但在我看来，管理员已经开始更多地了解该项目的工作原理和编写方式。 有时我们甚至会互相分享一些细节。 平均发布时间已缩短至一个小时。 有时我们会在 30-40 分钟内完成。 错误数量已显着减少，甚至减少了十倍。 当然，其他因素也影响了发布时间的缩短，例如自动测试。 每次发布后，我们都开始进行回顾。 以便整个团队了解新增内容、更改内容以及删除内容。 不幸的是，管理员并不总是来找他们，好吧，管理员很忙......我作为开发人员的工作满意度无疑增加了。 当您能够快速解决您能力范围内的几乎所有问题时，您就会感到自己处于领先地位。 后来我会明白，在某种程度上我们引入了 DevOps 文化，当然不是完全的，但即使是转型的开始也令人印象深刻。
第三个故事
启动。 一名管理员，小型开发部门。 抵达后我完全是零，因为…… 除了通过邮件之外，我无法访问任何地方。 我们写信给管理员并请求访问权限。 此外，有信息表明他知道新员工以及需要颁发登录名/密码。 他们提供从存储库和 VPN 的访问。 为什么要授予对 wiki、teamcity、rundesk 的访问权限？ 对于一个被叫来编写整个后端部分的人来说毫无用处。 只有随着时间的推移，我们才能使用一些工具。 当然，他的到来遭到了不信任。 我试图通过聊天和引导性问题慢慢了解该项目的基础设施是如何运作的。 基本上我什么都不认识。 生产与以前一样是黑匣子。 但更重要的是，即使是用于测试的阶段服务器也是一个黑匣子。 除了从那里部署 Git 分支之外，我们无能为力。 我们也无法像 .env 文件那样配置我们的应用程序。 不授予此类操作的访问权限。 您必须请求在测试服务器上的应用程序配置中更改一行。 （有一种理论认为，管理员感到自己对项目很重要，这一点至关重要；如果不要求他们更改配置中的行，那么他们就不会被需要）。 嗯，一如既往，不是很方便吗？ 这很快就会变得无聊，在与管理员直接对话后，我们发现开发人员生来就会编写糟糕的代码，本质上是无能的人，最好让他们远离生产。 但这里也来自测试服务器，以防万一。 冲突正在迅速升级。 与管理员没有任何沟通。 由于他孤身一人，情况变得更加糟糕。 下面是一张典型的图片。 发布。 某些功能不起作用。 我们花了很长时间才弄清楚发生了什么，开发人员的各种想法被投入到聊天中，但在这种情况下，管理员通常会认为开发人员应该受到指责。 然后他在聊天中写道，等等，我纠正他。 当我们被要求留下一个故事并提供有关问题所在的信息时，我们会收到有毒的借口。 就像，不要把你的鼻子伸到不该伸的地方。 开发人员必须编写代码。 当一个项目中的许多身体动作都由一个人完成，而只有他才能执行每个人都需要的操作时，这种情况是极其悲伤的。 这样的人，是一个可怕的瓶颈。 如果 DevOps 理念努力缩短上市时间，那么这样的人就是 DevOps 理念最大的敌人。 不幸的是，帷幕就此关闭。
PS 在与人们聊天中谈论了一些开发人员与管理员之后，我遇到了和我有同样痛苦的人。 但也有人表示，从来没有遇到过这样的事情。 在一次 devops 会议上，我问 Anton Isanin（阿尔法银行），他们如何以管理员的形式处理瓶颈问题，他说：“我们用按钮取代了它们。” 顺便一提 有他的参与。 我愿意相信，好的管理员比敌人多得多。 是的，开头的图片是真实的对应。
资料来源：www.habr.com