大约一年前，摆在我面前的是一项相当艰巨的任务：为经理们安排一个2小时的讲座，讲述敏捷和DevOps的故事。
因此，我开始从敏捷培训的软技能层面回到IT领域。 根据组织者的说法，超过1000名产品经理参加了本次讲座，其中大约48/50人在我的课堂上第一次听到“ Load Balancer”一词。
我什至得到了一个喜剧性的神灵：“一个出色的平衡器，无需停机即可进行更新的掌握，无需编程即可进行A / B测试的价格便宜，并且通常让经理睡个好觉。”
当然，IT部门的同事可能会对这种简化感到嘲笑，甚至为世界不同意“平衡器”一词以及应引起多少关注而感到愤怒。
但是，当在我的健身房中，有50个人中的48个人没有听到负载均衡现象时，这有点令人难过。 是的，某些移动应用程序后端的开发人员，甚至大型银行也可能因缺乏此类方案而犯罪。
例如，我最喜欢的黄色银行在莫斯科时间上午5点每周大约两次更新移动应用程序的后端服务器。 我怎么知道 因为在新西伯利亚，我要在2016年再住一年，那时已经是上午9点，错误000突然出现在我眼前，很难想象这已经是远东地区的午餐了。
如果管理人员在预算服务器容量时考虑容错能力，也许我们有机会使这个世界变得更好一点，并且不会有一台服务器用于所有功能，而是一个相当相称的风险和系统负载配置。
怎么了
当然，在设置任何任务时会出现第一个问题：为什么？
有这样一个框架：我们为什么需要它？ | 他们为什么需要它？
我们为什么需要它？
如果我们想象“我们”中有很多来自IT的人，不仅是开发人员和相关专家，还有技术顾问，HR和敏捷教练，他们每天都与没有IT背景的经理联系。
就我自己而言，我很简单地回答了第一个问题：提高经理的技术素养大大减少了任务不足的可能性，并提高了开发人员的满意度。
他们为什么需要它？
为什么真正远离IT的经理知道这一点？我们都是人，我们都想和平睡觉。 管理人员通常会对自己无法真正影响的事情负责。 在这种情况下，压力水平可以与有恐惧症的飞机乘客相媲美。
这可能是唯一一个不会像“势不可挡”那样的论点，“你怎么不知道这样明显的事情”或“任何人都必须在晚上蒙上一个不定积分才能蒙上眼睛”。 以我的经验，如果一个人“控制台上的肘部”，即使不自觉地也可以，但他通常可以使用这种印章进行操作。
如何解释复杂的简单图片
下面的插图并没有要求绝对的真理，也没有独立的价值，特别是因为在构建容错体系结构时不应将这些简化用作操作指南，因为我不打算在其中绘制各种细微之处，例如缓存。 这只是一个简化的模型。
在成人学习中，新信息的吸收是学习的一部分，重要的是要理解任何信息都必须重复至少三遍，以增加实际获取信息的可能性。
例如，这样的方案很可能与模因“不要试图离开鄂木斯克”相关联，而只是以“一切都很复杂，但他们也想要很多服务器”的思想来确认这个人。
但是，首先显示的此方案可以使人将“ balancer”一词与平衡服务器负载的现象联系起来。 没有任何保证可以正确理解此过程，但是拥有确信存在的知识以及为什么需要这样做。
让我们在这里破坏一下
敏捷清单的几点，然后说：“也就是说，在不降低右侧内容价值的情况下，我们对左侧内容的重视程度更高。”
例如，由于此方案使您可以了解如何在不编写大量源代码的情况下配置A / B测试系统，以及在此之前不费吹灰之力就如何更新服务器（对于管理员，而不是管理员）。
接下来是什么？
正是这种理解为管理人员开辟了通往CI / CD美好世界的道路，因为如果我们已经知道使基础结构部分容错的最低劳动力，那么我们就不必担心频繁发布。 这从根本上改变了总体上更新策略的方法。
好吧，我不是要告诉您较小的编辑占用了容量的1/10（即使它是3台服务器中的1台，但分配给它的流量却只有10％），这在升级过程中极大地降低了热情。 即使服务器每10个请求完全停止处理一次。
我们曾经在RPS 600上下降了20％，但是很快就被淘汰了，即使没有人的参与也似乎很快。 那时，作为负责技术指导的所有技术负责人，我几乎开始向其他管理人员重复“平衡器”一词。
正如我的经验所示，这些知识非常有用，因此管理员可以了解如何最大程度地降低发布所带来的风险，并对CI / CD和各种技术实验产生兴趣。
大约4年前，在我的实践中，大致相同的故事是向开发人员介绍类似于GitFlow的“分支”系统，以稳定版本和在钩子级别受支持的发布分支中的提交暂停，但最近它变得越来越少了而且需求更少。
我认为，现在提高非技术经理的技术素养确实非常重要。 当然，绝对不必采用这种方式。