在錯誤中能夠學到更多。
有兩個設計教訓，分享下。
IP 封禁
多主機多IP 網路封禁。原型圖如下：執行封禁操作之後，會生成若干條響應記錄和對應操作歷史記錄。
已有的元素響應（程序、檔案、容器、主機），都一個主機一個元素一條響應記錄。我最開始理解成，每個主機每個（拆分後的）IP（如果是 CIDR 或 IP段，則拆分成多個IP）一條響應記錄。沒有與產品同學確認。刷刷刷，很快實現了。產品走查時，發現這樣不合理，因為一個 IP段或CIDR 會拆分出很多響應記錄，如果有萬臺主機，則響應記錄是 len(IPs) * 主機數。很可能一次全部主機的封禁操作是百萬級記錄。
於是與產品當時討論了兩種方案：
- 每個主機每行（可能是一個IP，CIDR，IP端）一條響應記錄。還是需要拆分，不過拆分數量少了些。
- 每個主機所有IP一條響應記錄。最簡單，但有一個缺點，如果使用者想要單獨解封其中一個IP，則只能全部解封，再單獨封禁一條。
當時因為走查是提測當天，且第二種方案不能支援針對其中單個IP單獨解封，而第一種方案與現有實現比較相近，容易實現，因此，選擇了第一種方案。
結果測試同學測試後，發現IP解封非常麻煩。 最後討論後，將這個feature打回了。幾經討論後，內部達成一致，沒有必要做那麼複雜，就每個主機所有 IP 一個響應記錄。
回顧這個例子，我能學到什麼呢？
- 為什麼當時會理解成拆分後的每個主機每個IP一條記錄？之前剛做過告警裡IP網路封禁，就是一個IP一個主機一條記錄。囿於開發人員實現思維，且這樣做解封操作就不用寫新的程式碼。
- 為什麼討論後，不選擇第二種方案？時間緊，改動較大，影響提測；第二種方案不能單獨解封，從產品體驗上不太容易接受（只能先全部解封再單獨封禁，體驗差一點）。
- 如果時間考量影響技術方案，那麼技術方案很可能會出問題，後續還得重新搞一遍。得不償失。時間較為充足的情況下，技術方案最好重點考慮產品設計和技術實現。
- 如果只考慮技術實現，不考慮產品設計，即使技術實現看上去沒問題，也得返工。
- 對於方案存在小的缺點，要深入討論，是否一定不可接受。方案一定要綜合權衡，不要侷限於一兩個優缺點。
- 如果有對偶操作，一定要考慮對偶操作是否存在問題。
- 產品設計評審時，要多從產品角度去思考如何做更合理，避免過早代入開發思維。
入侵看板
入侵看板是關於告警的一系列統計圖表。之前入侵看板測試反映效能較慢，討論了用統計方法的可能性。因此，一開始就打算用統計方法來做入侵看板，沒有去思考其它放方案可能性。具體而言，就是先基於原始表及統計指標用定時任務統計到一張中間統計表上，然後再基於統計表做各種圖表。這樣，統計表的資料條數很少，效能問題就能解決。
不過實際做起來，發現統計方法其實有很多問題：
- 許可權控制很難搞。有主機、叢集、業務組、namespace 許可權維度。意味著每個維度每個指標都需要統計。
- 變更處理較多。尤其是告警狀態，有很多變更場景。告警打標、元素響應、修復驗證、加白、事件處理等。每個變更場景針對多個許可權維度都需要更新，更新邏輯複雜。
- 排查問題很難。由於每個資料是一個整體，如果出錯了，很難推斷出是哪裡出錯了，而且一次錯持續錯，幾乎沒有補救辦法。
- 程式碼侵入性強。每個變更處理都需要在相應程式碼裡嵌入一段統計變更程式碼，影響現有流程，容易出問題。
- 技術框架侷限性。 目前公司技術棧主要限於 mongo, redis，部署大多是單臺獨立部署，要引入新的大資料平臺和元件，在部署上都是較大的成本。很難僅僅為了看板功能引入新技術新元件來增大部署成本。
僅僅只是為了一個效能目標，要冒這麼多技術風險，實在是不划算。後來，我想了下，統計方法適合什麼場景呢？
- 變更少的場景。比如訂單、商品、金額等，這些一旦確定幾乎就不會變化了。統計方法明顯不適合於業務變更比較多的場景。
- 區域性最佳化場景。如果某個指標非常重要且實在太慢，可以針對這個指標單獨用統計方法最佳化。範圍小可控。
這個例子中，犯了什麼錯誤？
- 先入為主。以為 A 方案在 X 方面不好， Y 方案在 X 方面可能有更好表現，就選擇 Y 方案，並不仔細考慮 Y 方案的諸多弊端。這也是一個技術方案綜合權衡的問題。方案考量切不可只侷限在少量點上。
- 沒有考慮其它方案可能性。當只有一種方案可選時，註定要承受這個方案的所有缺點。如果這些缺點有一個是致命的，那麼這個方案就是不合理的。
產品設計和技術方案要嚴格把關
即使是經驗豐富的開發者，犯錯也是很難避免的。只是可以避免大多數錯誤，但仍然避免不了犯錯。
在研發流程中，產品設計評審和技術方案評審環節一定要嚴格把關。產品設計不當，嚴重的就是返工，用另一種設計再做一遍，耗時耗力； 技術方案不當，嚴重的是按另一種設計方案重新再做一遍，耗時耗力。
產品設計上，就專注思考產品設計上的合理性，避免過早代入開發思維（除非產品設計可能會導致較大的效能或資源開銷問題）。反覆與產品同學確認自己的理解不存在偏差。技術方案上，多考慮幾種方案，列出所有利弊，綜合權衡，多審查幾遍，請人幫忙一起把關。
不可不察之。
技術方案避坑
- 儲存設計：表設計維度正確，外來鍵或內嵌關聯合理。避免將量級大的欄位放在量級小的維度的表裡。比如將告警ID放在檔案上傳任務表裡。
- 質量屬性：提前考慮效能和穩定性。審查是否存在大資料量或耗時大的操作，用索引、併發、非同步、快取、預處理等方式來處理。
- 業務邏輯：考慮變更處理和關聯處理。如果不同功能之前存在衝突（ 比如歸併與響應），則需要站在更高的層面思考兩者的處理，而不是遇到一個問題解一個（很可能會解決一個問題同時引入另一個問題，直到改不動為止）。
- 擴充套件性：適當考慮擴充套件但不過度。不要想著一開始就設計很多特性，很可能跟業務場景不匹配而用不上。擴充套件性是為業務而服務的。
- 可維護性：考慮程式碼侵入性（改動散佈）。如果要在很多地方做相似的改動，考慮切面等。
- 資料：有大量資料分佈在伺服器上，要考慮資料分佈均衡。
- 互動：不要讓前端或外部直接依賴內部欄位結構。因為如果有一天需要修改欄位的話，可能就改不動了。