對於大多數科技公司,分頁是一個不爭的事實。重大問題出現時你的軟件,你需要的人可以迅速行動和應對它為了減少對客戶的影響你。manbetx万博全站客户端組織計劃和管理這一過程如何產生重大影響,你在多大程度上能夠響應事件和你能夠減少人數多少這些情況你的團隊。
在銅焊,我們已經在過去的一年工作執行重大變化我們處理頁麵的方式。從曆史上看,我們的DevOps團隊站在前線pages-even時如果是應用程序代碼,而不是基礎設施,造成問題,沒有明確的途徑升級產品工程團隊。這是從來沒有一個理想的方法,但在去年年初很明顯,它可能不再與我們的組織規模;我們需要找到一些方法來確保產品工程可以提供24/7的支持我們自己的代碼。另外,我們組織了雄心勃勃的目標為提高係統的穩定性和性能。我們設定了雄心勃勃的服務水平目標(SLOs)時,需要能夠確保我們的係統有問題,他們是固定的快。釺一直多年來迅速增長我們現在發送超過二十億消息(和攝取數十億數十億事件)每一天,所以這就需要建立一個更加健壯的生態係統培訓,優先級,並支持與我們的大規模擴展連接,實時係統。
就其本身而言,這種級的變更需要重大努力。但在釺,有皺紋,複雜的事情:在我們的基礎設施是一個重心龐然大物。與一個標準的服務架構,頁麵發送從一個服務;特定服務的團隊,擁有然後指控做出回應。用鐵板一塊,然而,一個給定頁麵的所有權可以模糊。因為多個釺團隊自己的代碼在這個龐然大物,我們必須應對的一個主要問題是如何確保所有頁麵都路由到相應的團隊。
請繼續閱讀的故事我們推出有效覆蓋我們的龐然大物,通過以下步驟:
- 優化我們的流程、基礎設施和代碼堅持持續改進的原則,增量變化,自動化
- 利用敏捷工作流並進行每天檢查每個頁麵的頁麵處理,確保根本原因分析……和正在采取的行動,以防止複發
- 從跨職能委員會組織變化利用的見解
第一步:組織一個委員會來驅動的結果
我們開始這個項目靈感來自過去的成功診斷和創建一個跨職能委員會,討論,和實現的變化我們需要分頁係統。我不能強調足夠的重要性這些委員會一直在推動組織變革。從許多不同的團隊代表跨多個不同的功能(和資曆水平)帶來了巨大的好處,包括:
- 更具代表性,更高的數量和更高質量的輸入整個過程
- 關鍵的見解來自不同團隊的征集和交付一個正在進行的基礎
- 整個公司的團隊成員準備提前更改委員會預計,減少摩擦,提高的結果
盡管釺並不明確亞馬遜的著名的“兩個披薩”規則當談到會議規模,我們努力確保所有委員會足夠小,真正的對話是可能的。(然而,看起來像很可能不同於組織)。然而,因為這項工作需要大量的跨團隊的排序和路由的頁麵,以及小組的流程更新,對我們至關重要,以確保我們團隊涉及到從所有相關的利益相關者和配備所需的上下文來幫助推出的變化。
第二步:支持我們
在委員會的首次會議,我們所有的鴿子頭為診斷的主要問題在起作用:
- 發送的頁麵數量是由應用程序代碼…但是是由隊友誰沒有寫代碼
- 一小部分的整體工程人員負責所有公司的非工作時間的支持
- 釺SLO目標,隻能與擴展的支持
- 在某些情況下,我們沒有跟進有效頁,導致可預防複發
很明顯,現狀需要改變。如果一個工程師在產品工程團隊寫non-performant代碼,例如,導致我們的排隊係統發送頁麵一夜之間,DevOps響應的團隊成員會缺乏關鍵的背景下如何解決這個問題解決複發和清晰的途徑。鑒於此,我們需要團隊誰寫的給定的代碼來支持它完全在production-both分類能力和在執行預防措施和增強功能。
第三步:確定誰擁有什麼
一旦我們同意,我們組織內團隊需要擁有和提供24/7支持離散,分別部署和測試庫,服務,和組件,我們需要找出該采取什麼措施。第一個?分離DevOps頁麵和產品工程頁麵。畢竟,我們不能通過團隊路線頁麵直到路由通過劃分奠定了基礎。
執行的第一步,我們整個重組PagerDuty配置,以確保我們有:
- PagerDuty代表我們的基礎設施的完整的服務
- 頁麵DevOps升級路線
- 頁麵產品工程升級路線
看起來像什麼?例如,它意味著DevOps收到頁麵與數據庫失敗,產品工程收到了大量的未處理的異常的頁麵,和兩個部門收到頁麵當我們的作業隊列是不健康的。(也就是說,我們仍然繼續頁麵DevOps升級不論什麼一段時間,直到產品工程升級人員配備齊全)。我們也PagerDuty配置起程拓殖簡化將來的變化和更加透明。
通過這一步,我們都能夠為我們的未來努力促進有效的頁麵分類和預防複發。
步驟四:團隊準備待命
繼續前進,我們的下一個步驟是定義一個旋轉的工程師做好準備,能夠分流問題在生產響應頁麵。做到這一點,我們知道我們需要有效地員工旋轉,提供相關的培訓和支持,快速迭代將反饋這個專業工作流程的改變。
當我們分開的頁麵被發送,我們使它成為一項重點,確保每個頁麵都有一個與之相關聯的runbook,培訓和許可協議是否已正確設置。進入這個過程,我們認為適當的組運行手冊將是必要的,從而能夠分流大多數生產問題,任何工程師訪問。盡管編寫運行手冊很有用,我們發現:
- 最簡單的運行手冊已經自動的,沒有理由使用人計算機能做的事情
- 頁麵沒有可自動化的運行手冊往往造成的複雜的問題,需要快速解決方案允許我們的大規模擴展,高性能係統維持SLOs;這意味著,在這些情況下麵臨的問題太複雜,讓我們編寫運行手冊,可以隨後在任何合理的時間
超出了困難我們發現在創建簡單的運行手冊對於大多數頁麵,我們還發現,大部分的頁麵我們收到在本質上是類型:一些地方沒有足夠快的工作,我們的排隊係統備份。顯而易見的,這些篩選頁麵是一種技能,需要教,因為大多數團隊目前不具備的知識解決這些業務問題。
鑒於此,我們決定開始與一群工程師工作在一個龐然大物旋轉。我們的計劃是在核心技能培訓的工程師需要診斷問題在大規模分布式係統和及時解決這些manner-then旋轉在新工程師和準備通過文檔,跟蹤和現場培訓。
下一步呢?形成工程分類隨叫隨到並開始測試我們的培訓和實施過程。
我們實際上滾出來,我們發現有一個工程師白天執行真正的係統移植,如禁用或節流住隊列的處理,是最有價值的部分之一的訓練。這些策略是更常見的步驟在一項決議,但很難優先考慮擁有一個實習生,行動在運動和生產問題時,更糟糕的是,可怕的讓他們不得不這麼做。練習的可怕的步驟當事情是安靜的被證明是很有價值的。
第五步:將“活”
我們與新的開始緩慢旋轉,從周一到周五,下午8點到8點的轉變。這一點對我們來說很重要,我們不從24/7開始的方法,因為我們知道,我們的計劃可能會有方麵需要改善和創造噪音我們迭代。讓我們采取這種方法,ever-patient DevOps團隊每一頁都繼續與我們合作。
產品工程收到我們的第一頁,我們每周監控和改進我們的工具進行生產問題。我們的事件管理儀表板也有一係列的迭代改進,增強我們團隊的可見性和可用性,包括:
- 創建一個鬆弛的通道,任何以翻轉與釺平台相關記錄,使其更容易調試問題從最近的狀態改變
- 自動化鬆弛文章隻要行動使用內部事件管理工具,提供快速可見性的行動已經由以前的工程師
並發努力我們也進行了一次徹底改革我們的角色、職責和流程來處理這類事件。通過實施正式的事故指揮官和溝通的聯絡人,逆轉錄病毒事件,和定期簽入動作條目相關的頁麵,我們發現事件確實發生運行更平穩,有更好的結果,跟進處理更可靠。
第六步:減少頁麵
產品工程團隊工作對24/7的所有權相關的頁麵,我們也優先做我們可以盡可能減少頁麵。確保我們已經清楚,跨團隊溝通在進入頁麵,我們把幾個關鍵步驟。
跟蹤頁麵JIRA
根據我們收到的每一頁,我們做了一個日誌記錄到JIRA董事會為此目的而創建的。董事會記錄響應頁麵的五個階段:收到一個新的頁麵,根本原因分析,跟進,跟進完成,和事件完成。
在我們的新工藝,一張卡片被要求呆在黑板上,直到與頁麵相關聯的潛在的問題已經固定。這可能意味著修複一個錯誤,改變頁麵配置,或釋放性能增強。
在每天的會議上回顧頁麵
以確保後續處理,我們成立了一個日常會議,審查進來的頁麵和被采取措施解決這些問題。會議包括一個旋轉群利益相關者從工程團隊,確保我們有集體知識需要確定根本原因,倡導下一個步驟,並處理有效地跟進。
這一努力已經償還。這些項目開始以來,我們已經看到頁麵體積下降,即使我們已經添加更多的團隊和更多的服務。通過跟蹤頁麵係統中我們使用我們的核心工作流作為一個產品工程團隊,我們能夠深度整合到現有的工作流。擁有一流的篩選過程和解決頁麵使所有團隊更好地理解背後的原因的問題影響我們的係統和采取預防措施,在這個每天會見的人有效地遵循這個過程成為可能。
第七步:24/7
一旦我們達到這一點,我們決定準備好了我們會推出24/7產品工程旋轉。關鍵的下一步我們必須決定誰將員工進行“非工作時間”旋轉。我們決定試著員工在自願的基礎上,然後采取額外措施如果那不是足夠;值得慶幸的是,我們能夠得到一個群體的誌願者,這樣就可以與24/7上線隨叫隨到的報道。
第一個星期有點粗糙。首先,事實證明,有些頁麵校準正常工作小時不需要火一樣經常設置。頁麵回顧會議中做出更改,但我們幾乎每一天,非工作時間的旋轉的第二個星期,我們發現事情是完全可控的。
最終的想法
在我們展望未來時,釺產品工程團隊將繼續關注迭代改善我們的過程和在生產中的應用。與此同時,我們將開始邁向確保我們的代碼更幹淨地分離成碎片,可以獨立測試,部署和支持。
考慮修改分頁的方法嗎?從我們的經驗與這些關鍵外賣:
- 使用跨團隊的委員會來監督這個過程可以確保您獲得最佳的輸入變化和組織中其他人的人可以參考狀態的東西
- 創建一個頁麵董事會可以轉型,從而能夠量化的風險係統和優先跟進更有效和有一個常規頁麵回顧會議是必要的,以確保董事會是有效利用
- 不斷改進和自動化的頁麵流程化合物整體有效性和節省很多時間和精力
想加入釺工程團隊?看看我們空缺職位在這裏。
