Categories
程式開發

為什麼系統越簡單,宕機時間越少?


為什麼系統越簡單,宕機時間越少? 1

據悉,馬士基Triple-E級集裝箱貨輪長1300英尺,可裝載18000個集裝箱,航程橫跨歐亞1.1萬英里,船上的所有船員都可以舒服的住在客艙裡。

以前,我曾經是一名造船工程師,現在在一家創業公司做營銷顧問。我發現,帶領13名船員駕駛世界上最大的集裝箱貨船,航行到半個地球之外的一個港口而不出現事故,這樣的經驗,同樣適用於有著業績增長需求的創業公司:

系統越簡單,宕機時間越少。

船上的系統比較簡單,易於操作,容易理解,所以即使出現問題也容易修復。如此,因故障停船的時間就會減少。對於一艘超大貨輪而言,“故障停船”意味著它被困於數千英里之外卻求助無門。這樣看來,“簡單”真的很有必要。

以船舶的操舵系統為例。方向舵由金屬桿向左或向右推動。這些金屬桿是由液壓驅動的,液壓由液壓泵控制。泵是由舵手室發出的電子信號控制。而信號是由自動駕駛儀控制的。當出現問題時,不需要船舶專家或造船工程師來尋找問題的原因和解決方案:

  • 如果自動駕駛儀失靈,就從舵手室手動操縱船隻。
  • 如果電子信號失效,可以到舵控室手動控制泵,同時通過一個簡單的聲能電話與艦橋通話
  • 如果液壓系統出現故障,可以使用機械連接的應急方向盤。
  • 如果機械裝置壞了,你可以在舵的兩邊各掛一根鏈條,朝你想要的方向拉!

為什麼系統越簡單,宕機時間越少? 2

與船舶類似,創業公司無法承受系統宕機的後果。銷售、市場營銷、網絡、客戶支持、招聘、產品和其他系統的長時間停滯可能會對增長率造成不可彌補的損害。

(雖然在現代船舶上自動化應用很多,但這些只會對做事情所消耗的時間和監控方便性產生影響。推進和輔助系統反而比以往任何時候都要簡單,這主要由於現代的柴油和電力推進系統取代了以往滿載管道的蒸汽發電裝置。)

為什麼簡單能減少宕機時間

1.可以快速熟練掌握

如果負責這個系統的人離開了、落水了或者被車撞了,又或者被安排到另一個項目中去,另一個人可以在沒有多少學習或培訓的情況下快速接手。這意味著很多人能介入並解決問題。

例如,用Tableau構建的分析儀表板可能比用自定義腳本和API拼湊而成的儀表板讓人更容易上手,解決問題。我們不應該讓數據科學家或產品開發人員來構建數據圖表展示程序,那樣程序就會變複雜。

2.排除故障花費的時間更少

在一個系統中,每個組件的行為及與其他組件關係越容易理解,排除問題並找到出問題組件(根本原因)也越快。

例如,如果一個公司在其網站上提供許多可下載的白皮書,並且它們都被限制在某一個表單(而不是每個白皮書對應一個自定義表單)之後,那麼當白皮書下載出現問題時,我們只需要排除一個表單和一個下載工作流的故障就可以了。

為什麼系統越簡單,宕機時間越少? 3

3.更多的可替代方案

當系統的每個部分功能清晰明確時,就更容易找到替代方案。

例如,假設有一個Salesforce流程,它使用自動化和第三方工具配合的方式來評分、篩選、分類和分配新的銷售線索。如果出現問題,那就很難找到替代方案。這會耽誤所有事情,直到該流程得到修復或被相似的解決方案替代。

現在,再來假設另一個銷售流程,在這個流程中,僅僅通知銷售團隊每一個新的銷售線索以及相關的細節,讓他們決定是否跟踪該線索。如果Salesforce通知步驟失敗,那麼很容易就會有100種其他方式將該信息傳遞給銷售團隊:報告、Slack通知、查詢信息列表、人工觀察,或者使用Zapier通過任意媒介發送警報。工作耽誤的時間最多只有幾分鐘。

為什麼系統越簡單,宕機時間越少? 4

初創公司案例

之前,我的一個客戶一直用一個比較老的企業營銷自動化平台(Marketo),並用該平台在幾年時間內構建了629個自動化流程。當某個東西壞了或需要調整時,150多名員工中只有一個人能做這件事。每個問題都需要幾天甚至幾週的時間來解決,而營銷活動只能停滯不前。每打一個補丁,整個系統都會變得更加複雜。

為什麼系統越簡單,宕機時間越少? 5

當那個人離開公司時,就沒有人會操作這個系統了。之後,每個星期都會出現一個新問題,比我們找到並修復它們的速度還要快。

為避免營銷運作陷入停頓,我趕緊將公司從Marketo遷移到HubSpot上,這是一個更簡單的平台,更易於操作和排除故障。

遷移只花了一周時間。然而,在這個過程中,另一個複雜的系統出現了:Salesforce。 Salesforce有10個自動化流程,100多個組合操作,所有這些都依賴於Marketo中各種微妙的定時自動操作。我們花了兩週時間(是遷移時間的兩倍)來理解並將這些流程與新的營銷平台集成。

為什麼系統越簡單,宕機時間越少? 6

總的來說,這兩個複雜的系統(Marketo和Salesforce)導致營銷團隊有六週的“宕機”時間,而銷售團隊有三週的“宕機”時間。這還不包括他們在過去幾年中經歷的“宕機”時間,也不包括如果我們不徹底檢查底層系統,他們將要經歷的“宕機”時間。

最後,我們的系統減少97%的進程(從629個減少到20個),不過卻提供所有相同功能。幾天后,一個被發現的bug在四分鐘內就解決掉。

這段經歷讓我總結出一些東西,是關於初創公司可以採用哪些原則來規避複雜系統陷阱的。

簡單系統的3大原則

“拆換”項目很痛苦,具有破壞性,即便從長期利益來看是值得的。許多創業公司就像船舶一樣,它們在初始階段沒有足夠時間和資源來進行大修。

以下是我在評估或實施新系統時要遵循的三條原則:

1.滿足特性並不一定要復雜

如果一個複雜的飛行控制系統總是讓飛機停飛,或者像Marketo這樣的企業營銷平台經常使營銷活動停滯,那麼它又有什麼用呢?

選擇易於操作的工具,而不是承諾提供最多特性的工具。

2.複雜的設想導致複雜的實現

如果解釋或理解一個設想需要太長時間,那麼實現它將會更加複雜。當某些東西不可避免地出現故障時,修復它的時間就會很長。

例如,一個銷售流程假如要演示一個小時,不管它看起來有多好,後期想要維護都很困難。

3.盡量改變而不是添加

當新的需求出現時,我們總是傾向於通過其它方式或在現有系統上集成添加新功能。實際上,我們應考慮是否可以通過改變核心系統來滿足新的需求。

就像從marketo到hubspot的遷移示例一樣,這個改變可能會導致預先的計劃停滯,但是從長期來看,停滯時間會更少(計劃外的)。

穩定最重要

事物越簡單,無序化的可能性就越小,對無序化問題的修復就越容易。 ——Thomas Paine, Common Sense, 1776

毫無疑問,人們在創業過程中肯定會遭遇挫折,就像在環球航行中一樣。然而,如果船上的系統很簡單又穩定,這些問題就不會讓創業公司無助地漂在大海中了。

英文原文:

Simple Systems Have Less Downtime