系統設計 – 靈活性 or 安全性？

摘要： 近日遇到一個這樣的決策問題，在這裡記錄一下。 公司有多種技術棧，每種技術棧的構建和釋出過程都不太一樣，那麼如何設計一套釋出系統滿足所有需求呢？ 這裡就存在2個不同的立場。 研發立場 一個是我站在研發角度看待，認為應該設計一套通用的流程，將構建、部署、啟動、停止等動作抽象為若干...

近日遇到一個這樣的決策問題，在這裡記錄一下。

公司有多種技術棧，每種技術棧的構建和釋出過程都不太一樣，那麼如何設計一套釋出系統滿足所有需求呢？

這裡就存在2個不同的立場。

研發立場

一個是我站在研發角度看待，認為應該設計一套通用的流程，將構建、部署、啟動、停止等動作抽象為若干的shell script hook，允許業務自定義實現，這樣就可以靈活的cover各式各樣的技術棧和玩法。

運維立場

但是運維對此持否定態度，究其原因在於該方案沒有足夠的安全性保證，它把流程的操控權交給了使用方，而不是標準化。雖然運維可以去review這些hook指令碼，但是的確太依賴於”人治”。不過該方案並不是不可行，而是需要根據公司規模來抉擇，比如我在百度時的noah平臺其實就是放權管理，因為實在很難為每一種技術棧玩法去做一套標準流程，

所以最終還是決定為公司的每一種技術棧訂製一套標準化的構建流程，通過為不同的技術棧提供不同的流程，填寫不同的構建引數，來保證流程把控在運維手中，因此更加安全。

有利就有弊，該方案的缺點就是如果要滿足業務方的需求，那麼就得改造釋出系統的實現去適應業務。

因為公司的各個技術棧玩法相對還是可控的，因此選擇為不同的應用架構分別訂製一套標準構建和釋出流程是更加適合公司的方案。