眾所周知，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 文化。

來源： www.habr.com