众所周知，CTO的能力只有在第二次担任这个角色时才会受到考验。 因为在一家公司工作几年是一回事，随着公司的发展，在相同的文化背景下，逐渐承担更多的责任。 在一家带着遗留包袱和一堆问题被巧妙地掩盖起来的公司直接担任技术总监是另一回事。

从这个意义上说，他在网上分享的 Leon Fire 的经历 开发运营大会，并不完全是独一无二的，但乘以他的经验和他在20年里尝试过的不同角色的数量，这是非常有用的。 剪辑下方是超过 90 天的事件年表，还有很多故事，这些故事发生在别人身上时很有趣，但亲自面对却不太有趣。

Leon 的俄语说得非常生动，所以如果您有 35-40 分钟的时间，我建议您观看该视频。 以下为节省时间的文字版本。

该报告的第一版对人员和流程的工作进行了结构良好的描述，其中包含有用的建议。 但她并没有将一路上遇到的惊喜全部传达出来。 于是，我改变了格式，把在新公司像玩偶一样突然出现在我面前的问题，以及解决的方法按照时间顺序呈现出来。

一个月前

和许多好故事一样，这个故事也是从酒精开始的。 我们和朋友坐在酒吧里，正如 IT 专家所预料的那样，每个人都在为自己的问题哭泣。 其中一位刚刚换了工作，正在谈论他在技术、人员和团队方面的问题。 我听得越多，就越意识到他应该雇用我，因为这些都是我在过去 15 年里一直在解决的问题。 我告诉了他，第二天我们就在工作环境中见面了。 该公司名为教学策略（Teaching Strategies）。

教学策略 (Teaching Strategies) 是针对出生至三岁幼儿课程的市场领导者。 传统的“纸质”公司已经有40年的历史，而数字SaaS版本的平台也有10年的历史，相对最近，使数字技术适应公司标准的过程才开始。 “新”版本于 2017 年推出，几乎和旧版本一样，只是性能更差。

最有趣的是，这家公司的客流量是非常可预测的——日复一日、年复一年，你可以非常清楚地预测到会有多少人、什么时间来。 例如，下午 13 点到 15 点之间，幼儿园的所有孩子都上床睡觉，老师开始输入信息。 这种情况每天都会发生，除了周末，因为周末几乎没有人工作。

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

该平台似乎只有 2 年历史，但拥有一个奇特的堆栈：2008 年的 ColdFusion 和 SQL Server。 ColdFusion，如果你不知道的话，很可能你也不知道，它是一个在 90 年代中期出现的企业级 PHP，从那时起我就再也没有听说过它。 还有：Ruby、MySQL、PostgreSQL、Java、Go、Python。 但主要的整体运行在 ColdFusion 和 SQL Server 上。

问题

越是与公司员工谈论工作以及遇到的问题，我就越意识到这些问题不仅仅是技术性的。 好吧，技术已经很旧了——他们没有研究它，但团队和流程都存在问题，公司开始理解这一点。

传统上，他们的技术人员坐在角落里做一些工作。 但越来越多的业务开始通过数字版本。 因此，在我入职前的最后一年，公司里出现了新的人：董事会、CTO、CPO和QA总监。 即公司开始投资科技领域。

沉重的遗产痕迹不仅存在于系统中。 该公司有遗留的流程、遗留的人员、遗留的文化。 这一切都必须改变。 我想这肯定不会无聊，就决定尝试一下。

两天前

在开始新工作的前两天，我到达办公室，填写了最后一份文件，与团队会面，发现团队当时正在解决一个问题。 就是平均页面加载时间跃升至4秒，即2倍。

从图表来看，显然发生了一些事情，但不清楚是什么。 结果发现问题出在数据中心的网络延迟上：数据中心的5毫秒延迟对于用户来说变成了2秒。 我不知道为什么会发生这种情况，但无论如何，我们知道问题出在数据中心。

第一天

两天过去了，第一天上班我就发现问题并没有消失。

两天来，用户页面的平均加载时间为 4 秒。 我问他们是否发现问题所在。

- 是的，我们开了一张票。
- 和？
- 嗯，他们还没有回复我们。

然后我意识到以前告诉我的一切只是我必须对抗的冰山一角。

有一句话非常适合这个：

“有时要改变技术，你就必须改变组织。”

但由于我在一年中最繁忙的时间开始工作，我必须考虑解决问题的两种选择：快速和长期。 从现在最关键的事情开始。

第三天

因此，加载持续 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张美容课门票已经是不错的成绩了。

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

结果我们得到：

• 减少站立和集会。
• 产品的主题知识。
• 一种主人翁意识。 当人们习惯于一直修补系统时，他们知道其他人很可能必须处理他们的错误，而不是他们自己。
• 小组之间的协作。 不用说，QA之前和程序员沟通不多，产品自己做事等等。 现在他们有共同的责任点。

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

第十一天

在改变团队架构的过程中，我发现了如何去算 故事点。 1个SP相当于一天，每张票包含开发和QA的SP，即至少2个SP。

我是怎么发现这一点的？

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

之后我们：

• 故事点评级系统已修订。 现在修复了可以快速通过系统传递给用户的小错误。
• 我们开始合并相关票证以进行开发和测试。 以前，每一张票、每一个错误都是一个封闭的生态系统，不与其他任何东西绑定。 更改一页上的三个按钮可能是具有三个不同 QA 流程的三张不同的票证，而不是每页一个自动测试。
• 我们开始与开发商合作研究估算劳动力成本的方法。 三天换一个按钮可不好笑。

第二十天

在第一个月中旬的某个时候，情况稍微稳定下来，我基本上弄清楚了发生了什么，并且已经开始展望未来并思考长期解决方案。

长期目标：

• 托管平台。 每个页面上数百个请求并不严重。
• 可预测的趋势。 乍一看，周期性的流量峰值与其他指标并不相关——我们需要了解为什么会发生这种情况并学会预测。
• 平台扩展。 业务不断增长，用户越来越多，流量不断增加。

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

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

• 反映项目的使命和目标；
• 优先考虑主要目标；
• 包含实现这些目标的时间表。

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

即组织KPI由团队支撑，团队KPI由个人KPI支撑。 否则，如果技术 KPI 与组织 KPI 不一致，那么每个人都会给自己裹上毯子。

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

您如何支持推出更多新产品的目标？

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

然后，可以在组内执行的各个 KPI 将位于主要缺陷所在的位置。 如果您专门关注此部分，则可以确保缺陷少得多，然后开发新产品以及支持组织 KPI 的时间将会增加。

因此，每一个决定，包括重写代码，都必须支持公司为我们设定的具体目标（组织发展、新功能、招聘）。

在这个过程中，发现了一件有趣的事情，这不仅成为了技术人员的新闻，而且成为了整个公司的新闻：所有门票必须至少关注一个 KPI。 也就是说，如果一个产品说要做一个新功能，第一个问题应该问：“这个功能支持什么KPI？” 如果没有，那么抱歉 - 这似乎是一个不必要的功能。

第三十天

月底，我发现了另一个细微差别：我的运营团队中没有人见过我们与客户签订的合同。 您可能会问为什么需要查看联系人。

• 首先，因为 SLA 是在合同中指定的。
• 其次，SLA 各不相同。 每个客户都有自己的要求，销售部门看都不看就签字了。

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

很明显，如果该平台基于 ColdFusion 和 SQL Server 1（2008 月份就不再受支持），那么我们距离 n-XNUMX 有多远。

第四十五天

大约第二个月中旬，我有足够的时间坐下来做 折扣值流制图 完全适用于整个过程。 这些是从创建产品到将产品交付给消费者所需采取的必要步骤，并且需要尽可能详细地描述。

您将流程分解为小块，看看哪些内容花费了太多时间，哪些内容可以优化、改进等。 例如，产品请求需要多长时间进行梳理、何时到达开发人员可以接受的票证、QA 等。 因此，您详细查看每个步骤并思考可以优化哪些内容。

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

• 从 QA 返回给开发人员的票证比例很高；
• 拉取请求审查花费的时间太长。

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

“你无法改进你无法衡量的东西。”

如何证明问题有多严重？ 会浪费几天或几个小时吗？

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

我们还添加了“审核中”，以了解平均有多少张票可供审核，从此您可以开始跳舞。 我们有系统指标，现在我们添加了新指标并开始测量：

• 流程效率： 绩效和计划/交付。
• 工艺质量： 缺陷数量，来自 QA 的缺陷。

它确实有助于了解什么进展顺利，什么进展不顺利。

第五十天

当然，这一切都是好的和有趣的，但是到了第二个月末，发生了一些原则上可以预见的事情，尽管我没想到会有这样的规模。 人们开始离开，因为高层管理人员发生了变化。 新人进入管理层并开始改变一切，旧人则退出。 通常在一家成立了几年的公司里，每个人都是朋友，每个人都互相认识。

这在意料之中，但裁员规模却出乎意料。 例如，在一周内，两名团队领导同时自愿提交了辞职报告。 因此，我不仅要忘记其他问题，还要专注于 创建团队。 这是一个漫长而难以解决的问题，但它必须被处理，因为我想拯救剩下的人（或他们中的大多数）。 为了保持团队士气，有必要对人们离开的事实做出某种反应。

从理论上讲，这很好：一个新人进来，他拥有全权委托，可以评估团队的技能并更换人员。 事实上，出于多种原因，你不能仅仅引入新人。 平衡总是需要的。

• 旧的和新的。 我们需要留住能够改变并支持使命的老年人。 但与此同时，我们需要引进新鲜血液，这个我们稍后再谈。
• 经验。 我和优秀的后辈聊了很多，他们都很渴望和我们一起工作。 但我无法接受他们，因为没有足够的前辈来支持后辈并充当他们的导师。 必须先招收高层，然后才招收年轻人。
• 胡萝卜加大棒。

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

第五十一天

我开始仔细观察团队，以了解我拥有的人，然后我再次想起：

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

我发现这个团队（无论是开发团队还是运维团队）都存在三个大问题：

• 对现状的满意度。
• 缺乏责任心 - 因为从来没有人通过表演者的工作成果来影响业务。
• 害怕改变。

改变总是会让你走出舒适区，越年轻的人越不喜欢改变，因为他们不明白为什么，也不明白如何改变。 我听到的最常见的答案是“我们从未这样做过”。 而且，这已经到了完全荒谬的地步——哪怕有丝毫的改变，也不可能有人不愤慨。 无论这些变化对他们的工作有多大影响，人们都会说：“不，为什么？ 这是行不通的。”

但如果不做出任何改变，你就无法变得更好。

我和一位员工进行了一次绝对荒谬的谈话，我告诉他我的优化想法，他告诉我：
- 哦，你没看到我们去年的东西！
- 那又怎样？
“现在比以前好多了。”
- 那么，情况就不能变得更好了吗？
- 为什么？

好问题——为什么？ 就好像现在比以前更好了，那么一切就足够了。 这导致缺乏责任感，这在原则上是绝对正常的。 正如我所说，技术团队有点袖手旁观。 公司认为它们应该存在，但是 没有人设定标准。 技术支持从未见过 SLA，因此对于团队来说这是相当“可以接受的”（这给我印象最深）：

• 12秒加载；
• 每次发布有5-10分钟的停机时间；
• 解决关键问题需要几天甚至几周的时间；
• 缺乏值班人员 24x7/待命。

没有人试图问我们为什么不做得更好，也没有人意识到事情不必是这样的。

作为奖励，还有一个问题： 缺乏经验。 前辈离开了，剩下的年轻队伍在前政权的统治下成长起来，并受到了前政权的毒害。

除此之外，人们还害怕失败和显得无能。 这表现在以下事实：首先，他们 在任何情况下都不会寻求帮助。 有多少次我们作为团体和单独交谈时，我说过，“如果你不知道如何做某事，就提问。” 我对自己充满信心，知道我可以解决任何问题，但这需要时间。 因此，如果我能在10分钟内询问知道如何解决的人，我会问。 你的经验越少，你就越害怕去问，因为你认为你会被认为是无能的。

这种对提问的恐惧以有趣的方式表现出来。 例如，你问：“这项任务你做得怎么样？” - “还剩几个小时，我已经完成了。” 第二天你再问，你得到的答案是一切都很好，但有一个问题，它肯定会在一天结束时准备好。 又一天过去了，直到你被钉在墙上并被迫与某人交谈，这种情况仍在继续。 一个人想要自己解决问题；他相信如果他自己不解决问题，那将是一个很大的失败。

这就是为什么 开发商夸大了估计。 也是同样的轶事，当他们讨论某个任务时，他们给了我这样一个数字，让我非常惊讶。 我被告知，在开发人员的估计中，开发人员包括从 QA 返回票证的时间，因为他们会在那里发现错误，以及 PR 所需的时间，以及应该审查的人员的时间它将很忙碌——也就是说，一切，一切可能的事情。

其次，害怕显得无能的人 过度分析。 当你说出到底需要做什么时，它会开始说：“不，如果我们在这里考虑一下怎么办？” 从这个意义上说，我们公司并不是独一无二的，这是年轻人的通病。

对此，我介绍了以下做法：

• 规则30分钟。 如果半小时内解决不了问题，请找人帮忙。 这取得了不同程度的成功，因为人们仍然不问，但至少这个过程已经开始了。
• 除去一切，只保留本质，在估计完成任务的最后期限时，即只考虑编写代码需要多长时间。
• 终身学习 对于那些过度分析的人。 这只是与人不断地合作。

第六十天

当我做这一切的时候，是时候算出预算了。 当然，我在花钱的地方发现了很多有趣的事情。 例如，我们在一个单独的数据中心有一个完整的机架，配有一台 FTP 服务器，供一个客户端使用。 事实证明“……我们搬家了，但他还是那样，我们没有改变他。” 那是2年前的事了。

特别令人感兴趣的是云服务的账单。 我认为云费用高的主要原因是开发人员第一次可以无限制地访问服务器。 他们不需要问：“请给我一个测试服务器”，他们可以自己拿走。 另外，开发者总是希望构建一个如此酷的系统，以至于 Facebook 和 Netflix 都会嫉妒。

但开发人员没有采购服务器的经验和确定所需服务器规模的技巧，因为他们以前不需要。 而且他们通常不太理解可扩展性和性能之间的区别。

库存结果：

• 我们离开了同一个数据中心。
• 我们终止了与 3 个日志服务的合同。 因为我们有 5 个——每个开始玩某些东西的开发人员都会拿一个新的。
• 7 个 AWS 系统被关闭。 再次，没有人停止那些已经停止的项目；他们都在继续工作。
• 软件成本降低了 6 倍。

第七十五天

时间流逝，两个半月后我就要和董事会见面了。 我们的董事会并不比其他董事会更好或更差；像所有董事会一样，它想知道一切。 人们投入资金并希望了解我们所做的事情在多大程度上符合设定的 KPI。

董事会每个月都会收到大量信息：用户数量、增长情况、使用哪些服务以及如何使用、性能和生产力，以及最后的平均页面加载速度。

唯一的问题是我相信平均值是纯粹的邪恶。 但向董事会解释这一点非常困难。 他们习惯于使用聚合数据进行操作，而不是例如每秒加载时间的分布。

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

也就是说，ColdFusion 通过 Jetty 和 nginx 并启动页面。 图像、JS 和 CSS 通过单独的 nginx 进行配置。 这是我所说的相当标准的做法 写 几年前。 结果，图片加载速度大大加快，并且...平均加载速度提高了 200 毫秒。

发生这种情况是因为该图是基于 Jetty 附带的数据构建的。 也就是说，快速内容不包括在计算中——平均值已经跃升。 这对我们来说很清楚，我们笑了，但我们如何向董事会解释为什么我们做了某件事，但事情却变得更糟了 12%？

第八十五天

第三个月末，我意识到有一件事我根本没有指望：时间。 我所说的一切都需要时间。

这是我真正的周历——只是一个工作周，不是很忙。 没有足够的时间来处理所有事情。 因此，你再次需要招募能够帮助你解决问题的人。

结论

那不是全部。 在这个故事中，我什至还没有了解我们如何使用该产品并尝试适应总体趋势，或者我们如何集成技术支持，或者我们如何解决其他技术问题。 例如，我很偶然地了解到，在数据库中最大的表上我们不使用 SEQUENCE。 我们有一个自己写的函数 nextID，并且它不用于事务中。

还有一百万个类似的事情我们可以谈论很长时间。 但最重要的还是要说的是文化。

正是文化或缺乏文化导致了所有其他问题。 我们正在努力建立一种文化，让人们：

• 不害怕失败；
• 从错误中学习;
• 与其他团队合作；
• 主动;
• 承担责任;
• 欢迎结果作为目标；
• 庆祝成功。

有了这个，其他一切都会到来。

莱昂火 在推特上, Facebook 和 中等.

关于遗留问题有两种策略：不惜一切代价避免使用它，或者勇敢地克服相关的困难。 我们c 开发运营大会 我们正在走第二条路，改变流程和方法。 加入我们 YouTube的, 邮件列表 и 电报，我们将共同实施 DevOps 文化。

来源： habr.com