众所周知，CTO能力仅是第二次扮演此角色。在公司工作几年是一回事，随着它的发展而发展，并且在相同的文化背景下逐渐承担更多的责任。这是另一回事-立即担任一家公司的技术总监，该公司的行李箱很旧，而且在地毯下整齐地注意到了许多问题。

从这个意义上说，他在DevOpsConf上分享的Leon Fayer的经历不仅是直接独特的，而且与他在20多年来为自己尝试的不同角色的经验和数量相乘也非常有用。在剪辑之下，历时90天的事件按时间顺序排列，还有许多故事发生在别人身上时会很有趣，但面对面却不那么有趣。

莱昂的俄语非常丰富多彩，所以如果您有35-40分钟的时间，我建议您观看视频。文本版本可以节省下面的时间。

该报告的第一版是对与人员和流程合作的结构化描述，其中包含有用的建议。但是她并没有传达出一路上遇到的所有惊喜。因此，我改变了格式，概述了新公司突然出现在鼻烟壶中突然出现在我眼前的问题，以及按时间顺序解决问题的方法。

一个月前

像许多好故事一样，这是从酒开始的。我们和酒吧里的朋友坐在一起，而且应该在IT人员中间，每个人都为他们的问题而哭泣。其中一位刚刚换了工作，谈论了他在技术，人员，团队方面的问题。我听的时间越长，我就越意识到他只需要雇用我，因为正是过去15年来我一直在解决的问题。我这样告诉他，第二天我们已经在一个工作环境中见面了。该公司被称为教学策略。

教学策略引领了针对从出生到三年的幼儿教育计划的市场。传统的“纸”公司已经有40年历史了，平台的数字SaaS版本为10。相对较早的时候，使数字技术适应公司标准的过程已经开始。 “新”版本于2017年推出，几乎与旧版本类似，只是效果更差。

最有趣的是，这家公司的流量非常可预测-每天，每年，您都可以非常清楚地预测会有多少人以及何时到达。例如，在下午1时至下午3时之间，幼儿园的所有孩子都入睡，老师开始输入信息。除周末外，每天都会发生这种情况，因为在周末几乎没人工作。

展望未来，我是在年度流量最大的时期开始工作的，出于各种原因，这很有趣。

似乎只有2年历史的平台具有一个独特的堆栈：ColdFusion和SQL Server 2008。如果您不知道，但很可能不知道，ColdFusion就是这样的企业PHP，它在90年代中期问世，从那时起，我什至没有听说过。也有：Ruby，MySQL，PostgreSQL，Java，Go，Python。但是主要的整体还是在ColdFusion和SQL Server上工作。

问题所在

我与公司员工就工作和遇到的问题进行的交谈越多，我越意识到问题不仅是技术上的。好的，这项技术很陈旧-当时还没有用，但是团队和流程存在问题，公司开始了解这一点。

传统上，技术人员坐在角落里做一些工作。但是越来越多的业务开始通过数字版本。因此，在我开始工作前的最后一年中，公司出现了新成员：董事会，CTO，CPO和QA董事。也就是说，公司开始在技术领域进行投资。

大量遗产的痕迹不仅存在于系统中。该公司拥有遗留流程，遗留人员和遗留文化。所有这些都必须更改。我认为这绝对不会很无聊，因此决定尝试一下。

前两天

在开始新工作的前两天，我到达办公室，填写了最后的文件，结识了团队，发现团队当时正为这个问题苦苦挣扎。其原因在于，平均页面加载时间跃升至4 s，即2倍。

从日程安排来看，显然发生了一些事情，目前尚不清楚。事实证明，问题出在数据中心的网络延迟：将数据中心的5 ms延迟对用户而言转换为2 s。我不知道为什么会这样，但是无论如何都知道问题出在数据中心。

第一天

两天过去了，在我的第一个工作日，我发现问题并没有消失。

在两天内，该页面的用户平均加载了4 s。我问他们是否发现了问题所在。

-是的，我们开了票。
-还有？
“好吧，他们还没有回答我们。”

然后，我意识到我以前被告知的一切只是我必须与之抗争的冰山一角。

有一个很好的报价非常适合这种情况：

“有时您需要更改组织来更改技术。”

但是自从我在一年中最忙的时候开始工作以来，我不得不考虑解决问题的两种选择：快速和长期。从现在的关键开始。

第三天

因此，加载需要4秒钟，并且从13到15个最大的峰。

在第三天的这个时间间隔，下载速度如下所示：

从我的角度来看，什么都没有。从其他所有人的角度来看，它的工作速度比平常要慢一些。但这不是那样发生的-这是一个严重的问题。

我试图说服团队，他们回答说他们只需要更多服务器。当然，这是解决问题的办法，但绝不是唯一，最有效的办法。我问为什么没有足够的服务器，多少流量。我对数据进行了推断，得出每秒大约有150个请求，这基本上可以满足合理的限制。

但是我们不能忘记，在获得正确答案之前，您需要提出正确的问题。 我的下一个问题是：我们有多少个前端服务器？答案“让我困惑”-我们有17台前端服务器！

-我不好意思问，将150除以17，结果大约是8吗？ 您想说每台服务器每秒跳过8个请求，如果明天每秒有160个请求，我们是否还需要2台服务器？

当然，我们不需要其他服务器。解决方案是在代码本身以及表面上：

var currentClass = classes.getCurrentClass(); return currentClass;

有一个getCurrentClass()函数，因为站点上的所有内容都在类的上下文中正常工作。而对于每页上的这一功能，有200多个请求 。

这种方式的解决方案非常简单，无需重写任何内容：只需不要再次请求相同的信息。

 if ( !isDefined("REQUEST.currentClass") ) { var classes = new api.private.classes.base(); REQUEST.currentClass = classes.getCurrentClass(); } return REQUEST.currentClass;

我非常高兴，因为我决定只有在第三天才发现主要问题。我天真，这只是众多问题之一。

但是，针对第一个问题的解决方案降低了计划的执行时间。

同时，我们进行了其他优化。可见很多东西可以修复。例如，在第三天的同一天，我发现系统中仍然有一个缓存（起初我以为所有请求都直接来自数据库）。当我想到缓存时，我会介绍标准的Redis或Memcached。但只有我这么想，因为在该系统上使用了MongoDB和SQL Server进行缓存-刚从中读取数据的系统相同。

第十天

第一周，我正在处理需要立即解决的问题。在第二周的某个地方，我第一次来到站台与团队交谈，看看正在发生什么以及整个过程如何进行。

再次发现了一件有趣的事。该团队由18名开发人员组成。 8名测试人员； 3名经理； 2位建筑师。他们都参加了共同的仪式，也就是说，每天早上有30多个人站起来，告诉他们他们在做什么。显然，会议没有花费5或15分钟。没有人听别人的话，因为每个人都在不同的系统上工作。通过这种形式，每小时在美容会议上有2-3张票已经是一个不错的成绩。

我们要做的第一件事是沿着产品线将团队分成几个部分。对于不同的部分和系统，我们确定了独立的团队，其中包括开发人员，测试人员，产品经理，业务分析师。

结果，我们收到了：

减少站立和集会。
产品知识。
有主人翁感。当人们以前经常谈论系统时，他们知道其他人可能必须使用他们的错误，而不是他们自己。
小组之间的合作。您不能说质量检查以前没有与程序员进行过多的交流，产品做了自己的事情，等等。现在他们有了共同的责任点。

我们主要关注效率，生产力和质量-这些是我们通过团队转型试图解决的问题。

第十一天

在改变团队结构的过程中，我发现了如何计算故事点数。 1 SP等于一天，并且每张票证都包含用于开发和质量检查的SP，即至少2 SP。

我是怎么找到这个的？

发现一个错误：在其中一个报告中，输入了需要报告的时间段的开始日期和结束日期，而没有考虑最后一天。也就是说，请求中的某处不是<=，而仅仅是<。有人告诉我这是三个故事要点，即3天。

之后，我们：

修订了故事积分评分系统。现在修复了可以快速通过系统传递的小错误，这些错误很快就可以到达用户手中。
我们开始结合相关的票证进行开发和测试。以前，每张票，每一个错误都是一个封闭的生态系统，没有附加任何其他内容。更改一页上的三个按钮可能是具有三种不同质量检查流程的三种票证，而不是一页上的一次自动测试。
他们开始与开发人员合作，以评估劳动力成本。三天换一个按钮并不好笑。

第二十天

在第一个月中的某个时候，情况已经稳定了一点，我弄清楚了主要的情况，并已经开始展望未来并考虑长期解决方案。

长期目标：

托管平台 每个页面上有数百个请求-这并不严重。
可预测的趋势。 乍看之下有周期性的流量高峰与其他指标不相关-有必要了解为什么会发生这种情况并学会预测。
平台扩展。 业务不断增长，越来越多的用户涌入，流量也在增加。

过去经常说： “让我们用[语言/框架]重写所有内容，一切都会更好！”

在大多数情况下，如果改写的代码根本不起作用，那么这是行不通的。因此，我们需要创建一个路线图-一个具体的策略，逐步说明如何实现业务目标（我们将做什么以及为什么这样做），其中：

反映项目的任务和目标；
优先考虑关键目标；
包含他们取得成就的时间表。

在此之前，没有人与团队讨论过进行任何更改的目的。这需要正确的成功率。在公司历史上，我们第一次为技术组设置了KPI，这些指标与组织指标挂钩。

也就是说，组织KPI由团队支持，而团队KPI已由单个KPI支持。否则，如果技术关键绩效指标与组织的关键绩效指标不一致，那么每个人都将自己笼罩。

例如，组织的KPI之一是通过新产品来增加市场份额。

您如何支持拥有更多新产品的目标？

首先，我们想花更多的时间开发新产品，而不是修复错误。这是一个易于评估的逻辑解决方案。
其次，我们希望支持交易量的增加，因为市场份额越大，用户越多，因此流量也就越大。

然后，可以在组内执行的各个KPI例如位于主要缺陷所在的位置。如果您专注于此特定部分，则可以减少缺陷的数量，然后增加开发新产品和再次支持组织KPI的时间。

因此，每个决定，包括重写代码，都应支持公司为我们设定的特定目标（组织的成长，新职能，招聘）。

在此过程中，出现了一件有趣的事情，这不仅成为技术人员的新闻，而且也成为整个公司的新闻：所有故障单都应集中在至少一个KPI上。也就是说，如果产品说要创建新功能，则应该问第一个问题：“此功能支持哪些KPI？”如果不支持，那么很抱歉-看来这是不必要的功能。

第三十天

在本月底，我发现了另一个细微差别，我的Ops团队再也没有看到我们与客户签订的合同了。您可能会问为什么要查看联系人。

首先，因为SLA是在合同中注册的。
其次，SLA都是不同的。每个客户都提出了他们的要求，而销售部门则不加签收。

另一个有趣的细微差别-在与最大客户之一的合同中，该平台支持的所有软件版本必须为n-1，即不是最新版本，而是倒数第二个。

很明显，如果平台使用的是ColdFusion和SQL Server 2008，则距n-1还有多远，而后者在7月份完全不再受支持。

第四十五天

在第二个月中的某个地方，我有足够的空闲时间坐下来，并为整个过程完全进行了价值流映射。从创建产品到交付给消费者，这些都是必须采取的必要步骤，您需要尽可能详细地对其进行绘画。

您将流程分解成小块，然后查看花费了太多时间，可以优化，改进的东西等。例如，产品请求经过修饰后要花多长时间，何时到达开发人员可以接受的票证，质量检查等。您仔细研究了每个步骤，并认为可以进行优化。

当我这样做时，有两件事引起了我的注意：

从质量检查返回给开发人员的回程票比例很高；
拉取请求审核花费了太多时间。

问题是这些结论是这样的：似乎需要很多时间，但是我们不确定多少。

“不可能改善无法衡量的东西。”

如何证实问题的严重性？它要花几天还是几个小时？

为了衡量这一点，我们在Jira流程中添加了几个步骤：“准备开发”和“准备进行质量检查”，以衡量每张票证等待的时间以及返回特定步骤的次数。

我们还添加了“正在审核”，以了解平均有多少票在审核中，这就是为什么它们已经开始跳舞的原因了。我们拥有系统指标，现在我们添加了新指标，并开始测量：

流程效率：绩效和计划/交付。
流程质量：缺陷数量，质量保证缺陷。

确实有助于了解进展顺利和不利的方面。

第五十天

当然，这一切都是很好而且有趣的，但是到第二个月末，原则上是可以预见的，尽管我没想到会有这么大的规模。人们开始离开，因为高层已经改变。新人们来到领导层，他们开始改变一切，而老人们则辞职了。通常在一家成立数年的公司中，所有朋友和彼此都认识。

这是预期的，但裁员规模出乎意料。例如，在一周内，两名团队负责人同时提出了自己的解雇申请。因此，我不必忘记其他问题，而可以专注于创建团队 。这是一个长期而艰巨的问题，但她不得不处理，因为她想拯救剩下的人（或其中大多数人）。有必要对人们离开这个事实做出反应，以保持团队道德。

从理论上讲，这是件好事：一个新来的人拥有完整的菜谱，可以评估团队技能并替换人员。实际上，您不能仅仅因为许多原因而结识新朋友。 总是需要平衡。

旧的和新的。我们需要留住可以改变和支持任务的老人。但是同时，我们需要注入新的血液，稍后再讨论。
经验。我和很多大三生聊了很多，他们都为自己而努力，他们想为我们工作。但是我不能接受他们，因为没有足够的君主来支持初中生并为他们提供指导。首先有必要获得最高职位，然后才是青年。
胡萝卜和棍子。

对于什么是正确的平衡，如何保持平衡，要离开多少人以及要推动多少人的问题，我没有很好的答案。这是一个纯粹的个人过程。

第五十天

我开始仔细查看团队，以了解自己的身份，并再次想起：

“大多数问题都是人的问题。”

我发现在团队中，无论是开发人员还是操作人员，都存在三个大问题：

对事物的当前状态感到满意。
缺乏责任感 -因为没有人将表演者的工作成果带到业务中来。
害怕改变。

改变总是会让您脱离舒适区，年轻人是年轻人，他们不喜欢改变的原因就越多，因为他们不了解原因，也不了解如何。我听到的最常见的答案是：“我们从未这样做过。” 到了完全荒谬的地步-没有人的愤慨，丝毫没有改变。人们说，所做的更改与他们的工作无关，人们说：“不，为什么？它行不通。”

但是，如果不进行任何更改，您将无法变得更好。

我与一名员工进行了绝对荒谬的交谈，我告诉他我的优化想法，他告诉我：
-啊，你没看到我们去年的情况！
“那又怎样？”
“现在比以前好多了。”
“所以没有比这更好的了吗？”
-为什么？

好问题-为什么？好像，如果现在比以前好，那么一切都很好。这导致缺乏责任，这在原则上是绝对正常的。正如我所说，技术团队有点过分。该公司认为应该做到这一点，但是没有人制定标准 。他们从未在技术支持上看到SLA，因此这对于该小组来说是“可以接受的”（这让我印象最深）：

12秒下载；
每个版本5-10分钟的停机时间；
关键的故障排除需要几天和几周的时间；
缺乏值班24x7 /随时待命。

没有人试图问为什么我们不应该做得更好，也没有人意识到应该做得更好。

另外，还有一个问题： 缺乏经验 。年长者离开了，剩下的年轻队伍在以前的政权下成长，并因此而受毒害。

所有这些，人们也害怕失败，似乎没有能力。这体现在以下事实：首先， 他们在任何情况下都没有寻求帮助 。我们在小组中和个别情况下进行了几次交谈，我说：“问一个问题，如果您不知道该怎么做。” 我对自己充满信心，知道我能解决任何问题，但这需要时间。因此，如果您可以问一个知道如何在10分钟内解决问题的人，我会问。经验越少，您害怕问的越多，因为您认为自己将被视为无能。

这种担心提出问题的恐惧以有趣的形式表现出来。例如，您问：“您如何完成此任务？”-“还有几个小时，我已经完成了。” 第二天再次询问，您会得到一切都很好的答案，但是有一个问题，到今天结束，它就会准备就绪。一天过去了，直到您紧贴墙壁并强迫某人讲话，否则一切都会继续。一个人想亲自解决问题，他认为如果不解决，那将是一个很大的失败。

这就是为什么开发商夸大了 。当他们讨论一项特定任务时，那是个笑话，他们给了我这么一个数字，令我感到非常惊讶。有人告诉我，在估算中，开发人员包括票证从QA退回的时间，因为他们在那里发现错误，PR将花费的时间以及需要查看票证的人员将很忙的时间-即所有内容那是唯一可能的。

其次，害怕显得无能的人不必要地分析 。当您说出确切需要做的事情时，它开始：“不，但是如果我们在这里思考呢？”从这个意义上说，我们的公司不是唯一的，这是一个青年问题的标准。

作为回应，我介绍了以下做法：

规则是30分钟。 如果半小时后仍无法解决问题，请寻求帮助。这取得了不同程度的成功，因为人们仍然不问，但是至少这个过程已经开始了。
在估算任务期限时，除了基本要素之外，请排除所有内容，即仅考虑编写代码需要花费多长时间。
过度分析者的继续教育 。这只是与人不断的工作。

第六十天

当我做所有这些事情时，是时候弄清楚预算了。当然，我在花钱的地方发现了很多有趣的东西。例如，我们在一个单独的数据中心中有一整个机架，在该机架上有一台FTP服务器供一个客户端使用。事实证明，“ ...我们感动了，但他留下了，我们没有改变他。” 那是两年前。

特别令人感兴趣的是云服务账单。我敢肯定，云服务大笔支出的主要原因是开发人员一生中第一次无限制地访问服务器。他们不需要问：“请给我一个测试服务器，”他们可以接受。另外，开发人员始终希望构建一个如此酷的系统，以使Netflix羡慕Facebook。

但是开发人员没有购买服务器的经验，也没有确定服务器正确大小的能力，因为他们以前不需要它。通常，他们并不完全了解可扩展性和性能之间的区别。

库存结果：

我们离开了一个数据中心。
用3个日志服务终止了合同。因为我们有5个人-每个开始玩游戏的开发人员都换了一个新人。
关闭了7个AWS系统。再一次，没有人停止死了的项目，它们都继续工作。
降低了6倍的软件成本。

第五十五天

时间流逝，两个半月后，我不得不与董事会见面。我们的董事会并不比别人更好，也不会更糟；它希望了解所有董事会一样的一切。人们投入资金，并想了解我们所做的工作与既定的KPI的匹配程度。

董事会每个月都会收到很多信息：用户数量，他们的成长，他们使用什么服务以及如何使用，生产力和生产力，最后是平均页面加载速度。

唯一的问题是，我相信平均值就是纯邪恶。但是董事会很难解释。它们习惯于使用汇总数字进行操作，而不是通过每秒加载时间的扩展来进行操作。

在这方面，有一些有趣的观点。例如，我说过，您需要根据内容的类型在各个Web服务器之间分配流量。