悲剧 （来自
德语 Tragödie，来自
拉丁语 tragoedia，来自
其他希腊语 τραγωδία）是一种艺术作品，旨在在一个情节将人物引向灾难性结局的舞台上进行演出。
大多数悲剧都是用诗歌写的。 这场悲剧是由Baruch Sadogursky（
@jbaruch ）和Leonid Igolnik（
@ligolnik ）
撰写的 。 如果我们在大规模讨论DevOps，那是什么悲剧？
本文以现实主义的严重性为标志，最明确地描述了一个大发展的现实，就像一堆内部矛盾一样。 它以极其强烈和饱和的形式揭示了现实中最深层的冲突，从而获得了艺术符号的价值。
现在我们完成玩Belinsky的比赛，并欢迎晋级！ 有文字和视频。 不要劫持人质！
如您所知，希腊人崇尚维恩图。 我们将向您展示多达三个-有关DevOps的全部信息。
DevOps有传统的描述-这是运营，开发和质量保证的交集。 从历史上讲，后来在这里添加了质量检查很有趣。
但是今天，我们将讨论其他内容-技术，流程和人员的交集。 关于获取这三个组件所需要做的一切。
现在再比较两个图表：
有时会发生。
五角大楼公司
让我们从一家名为Pentagon的神话公司开始这个故事，该公司处理信用卡交易。
第一幕-消防员
人 。 该公司刚刚开始工作，只有三名工程师。 这三个人都来自同一家国防公司。 这些家伙足够聪明，所以他们拥有一切：JavaScript，Node，React，Docker，微服务。
工艺流程 。 当一个团队中有三个人时，该过程将是什么样的？ 看板：在纸上或在Trello。 他们很聪明，从一开始就了解需要进行质量检查，因此需要进行TDD，单元和集成测试。 没有行动，所有人都有根。
工具类 相应地，对于三个仅提出一些东西的人：
JIRA ，
GitHub ，
Travis CI等。
让我们谈谈这些人如何生活在这个美丽的栈上。 首先，和优秀的初创公司一样，我们正在锯，锯产品并等待第一个客户。
突然间，奇迹发生了-组织后苏联时期最好的会议的一个组织决定信任这些人并通过他们进行交易。
真正的创业公司在获得第一个客户时会做什么？ 庆祝！ 晚上三点左右，当一切都处于
特殊状态时，客户打电话说什么也没用。
当然，首先要慌张！
下一步就是战斗！ 例如，我们查看日志。
我们看了看，结果发现我们的三个英雄之一-瓦西娅（Vasya）在节日过后回到家，实现了他的小想法。 我们记得在提交和测试通过之后，所有东西都投入生产。
好吧，我们哪个没有失败？ 我们不会怪Vasya。 回滚到上一次提交。 它不会去！ 由于某种原因，没有足够的库，称为左键盘。
对于那些不知道左键盘发生了什么的人，我们告诉他们。 因此，
2016年3月23日，一半的互联网中断了 。 通常，JavaScript中的左键盘模块仅在行的左侧插入空格。 互联网的一半直接或间接依赖于此模块。 左手垫的作者设法与中央npm存储库的所有者发生争执，因此他离开了他们，把所有的工作都带走了。 npm通常是一个神秘的系统：添加新模块进行下载时，它们不仅会检查，还会检查所有旧模块。
因此，一场又一次的战斗继续进行。 问题一直存在。
第二幕-火灾警报安装程序
公司新闻：筹集资金，找到一位投资者，雇用了27名员工，其中一名具有运营背景。 共有100位客户出现，甚至提供了技术支持。
因此，该过程还必须进行升级。 出现了普通Scrum探索性测试。 我们意识到NoOps根本不存在，因为这里有Ops（如果架构是无服务器的，那么服务器仍然在那里，那不是你的）。 由于夜间唤醒整个团队是错误的，因此出现了待命的开发人员。
因此，工具集已经扩展。 至少，知识库已经出现，因为现在有一个服务员，他需要在某个地方寻找信息。 另一个新颖之处是
JFrog Artifactory ：该系统可让您存储昨天停靠的内容，以便您可以轻松回滚（使用左键盘的课程没有白费），而无需重新构建。 我们安装了一个用于收集日志并进行搜索的系统。
已添加
Pingdom-迷人的监视系统：您给它提供一个url，它告诉您它是否有效或崩溃。
因此，此时他们又筹集了资金。 因此，我们注意到。 星期五，凌晨三点，客户致电。 某些方法不起作用：Visa和MasterCard通过，但American Express无法通过。
当客户凌晨三点打来电话时，技术支持会如何反应？ 惊慌！
然后我们打电话给服务员。 猜猜谁在值班？ 当然，Vasya！ 猜猜Vasya处于什么状态。 是啊 但是Vasya齐心协力，看看支持者给了他什么，并说他对此非常怀疑，他已经做到了。 因此，Vasya只需进行维修。 每个人都将入睡。 汇报从星期一开始。
这是我们为知识库制作的特定文档的示例，因此，如果再次重复某些内容，则可以快速找到它。 此外，有时还会向客户显示：
该文档显示主要标题，原因，特征和事件列表。 必须指出症状，并给出有关到底发生了什么以及如何修复的技术描述。 该文档最重要的部分是发生故障的关键原因。
对于Vasya，我们有日志队列溢出。 您需要清除它的信用卡交易记录，并增加其大小。 例如，在42！
这样的过程对于内部的持续改进是非常好的，并且保证了安装那些相同的“烟雾探测器”。 该文档很重要的第二个原因是向客户的报告。 一些服务在“放置”一段时间后，会公布其原因。
有时问题被证明是灾难性的，因此不值得讨论。
在
2017年2月的 GitLab
中 ，一个人删除了生产数据库。 这是GitLab上传的分析：
因此，在某处有备份，只有没人知道在哪里。 然后找到了备份，但结果却是空的。 是的，有一个基本转储。 但是它是用不同版本的postgres制作的，因此不合适。 我们有快照，但没有数据库。 由于缺少数据，从S3进行的复制也不起作用。
因此，五种不同的数据备份技术不起作用。 我们认为此书无法发布，因为没有其他人会信任他们。 但是，根据您的谈论方式，客户可能会原谅。 是的，只有一次。
顺便说一句，做到这一点的那个人得到了晋升。 此外，他将自己的Twitter状态更改
为GitLab的数据库（删除）专家 。
第三幕-高潮
那么我们公司正在发生什么呢？ 他们再次筹集了资金，雇用了一群人-现在我们有5名操作工程师和1名从事表演的人。 有一位首席建筑师。 一个客户成功团队已经出现，涵盖了可能需要支持的所有行业。 他们放慢了速度，以便团队的其他成员可以继续工作。 通常在这样的团队中，有一个可以与运维或支持建立关系的团队，并且还需要定期在这里让工程师陷入混乱，冲刺或一个月之久。 公司发展壮大，律师和财务总监出现了。 客户群已增长到1000。
随着团队的成长，开发过程必须改变。
SAFE出现了-一个框架，该框架解释了在有很多团队或开发中心的情况下如何做Scrum-不止一个。 “保险箱”中存在的多个进程可以杀死一匹马，但是如果只能全部采取一次。 如果仅除去公司发展阶段所需的那些零件，那么一切都会很好。
当大型团队有某些需求或您有一个庞大的系统需要构建某些东西时，就会出现系统测试。 各个Scrum团队可以很好地测试他们的系统，但是应该对整个系统应在生产中组装的事实负责。
行动团队呢？ 如前所述，有两种方法可以进行DevOps。 首先是本书，以及Netflix，Google和Twitter的说明。 第二个是在现实生活中，并非所有工程师都能在生产中扎根。
升级路径是一个重要的概念，可让您在给定的时间解决任何问题，因为在升级路径的末尾有CEO的移动电话，在接到电话后，所有问题在5小时58分钟内消失了。
SOC II-卖方提供给客户的一组标准。 这些标准确认该公司具有某些安全解决方案，即分工的方法。
待办事项-改进系统需要解决的问题列表。 通常，后架构师将成为首席架构师，他必须查看系统需求和产品需求并确定这些任务的优先级。
当然，工具也正在改进。
还有更多新闻。 Vasya被提升。 他现在是工程副总裁。
星期五，星期六，星期日通过-没有任何反应。 一切正常。 每个人都震惊。 星期一到了，一位律师来到Vasya，说他正在参加一次律师会议，并在那里听说过LGPL 2.2。 Vasya不知道他们是否拥有LGPL 2.2。
人们工作了很长时间，然后才发现LGPL 2.2。 需要削减。 但这是由系统的正常运行所消除的，明天没有人取消发布。 好吧，什么都没有处理。
基金总监来到瓦西亚：
- 您需要多少钱用于服务器和生产？ 制定明年的预算...
- 42-瓦西亚说。
我们也解决了这个问题。
他们来到Vasya并说有潜在的客户，但是他担心我们从来没有这么大的客户，因此想确信它会很好。 从历史上我们知道，现阶段每个人都死了。
但是，由于我们必须有一个幸福的结局，我们将其附于希腊的悲剧。
结语-积极改进
现在让我们谈谈扩展DevOps的最后阶段-主动改进。 关于防火。
人们没有任何变化。 但是有了这个过程-非常如此。
由于我们有一名性能工程师，因此必须以某种方式监视系统。 许可证和安全管理出现了。 主动表现-现在，我们正在仔细观察关键指标在哪里移动并修复问题，然后再开始大火。 在扩大产品规模时，建议您说一句话：如果您想拥有微服务，那么至少它应该具有标准的监控，日志等。
因此，有支持所有这些功能的工具。 例如，用于许可证和安全性监视的工具是
JFrog Xray 。
火焰计 -由于现在具有主动性能，因此您需要以某种方式生成负载。 诸如Service Virtualization之类的事情正在兴起，它允许您将模拟对象用于远程API，因为并非您与之合作的每个供应商都可以提供测试API。
解析中
让我们分析先前行为的一些事件。
还记得瓦西里用手指指着天空计划预算的情况吗？ 在使用我们的一种产品时，我们想弄清楚正在花什么资源。 将待办事项中的所有内容分组后，我们得到了以下图表：
我们错误地认为我们在大型功能A上花费了80％-实际上，它仅花费了13％。 同时，多达34％的产品保持常亮-产品中需要完成的工作：修复错误，更新库等。
实际上，只有一个客观的产品质量指标：客户满意度，这在支持电话中得到体现。
第二个例子。 我们解决了所有关键缺陷：
65％的票证属于关键级别的第一级。 这是一场噩梦吗？
现在，获取相同的数据，并从另一个角度看待它。
现在该图表反映了汇报后的情况。 事实证明，工程师使用所提供的信息关闭了52％的票证，也就是说，他向支持者写了他们不知道的信息。 只有大约20％的门票因某种代码更改而关闭。 因此，事实证明研发并没有错。 甚至连支持都不怪。 实际上，我们缺乏培训-和Vasya一样，工程副总裁在看到他花了很多时间在各种废话上之后，派了一大堆工程师来训练支持。
他们纠正了瓶颈中的文档，更正了日志。 结果，花费了很多开发人员时间的那一部分消失了。
结论
在消防，安装警报和主动解决问题的各个阶段，都需要安装许多流程，人员，专家，方法和工具。 所有这些不可能在一天内完成。 另外，在开发的某些阶段不需要某些东西。
重要的是要了解在人员，流程和工具中不断需要改进。
到底有什么需要改进的地方，我们将被帮助找出所谈论的数字。 只有根据这些数据，我们才能正确地决定在哪里投资时间和前进的方向。
并且不要忘记DevOps的两个基本原则：
在下一个星期日，Baruch和Leonid将在圣彼得堡的DevOops 2018上发表报告“ #DataDrivenDevOps” 。 来吧，会有很多有趣的事情：这是报告 ，这是约翰·威利斯 ，这是与BoF和卡拉OK的聚会。 等着你！