思考：
-
現目前的架構是什麼？業務邏輯？
研發一台，測試&生産共用一套k8s叢集。
目前前端已經遷移到k8s，生産後端暫時沒有上k8s。
-
造成目前架構的原因是什麼？
曆史遺留原因 造成架構不合理
-
那些地方不合理，為什麼？
（1）.使用經典公網模式，會自動配置設定區域網路ip位址 ， nginx-ingress-controller lb沒有固定
（2）.使用名稱空間做測試和生産環境的隔離，安全幾乎無保障
（3）.線上隻有一套環境而且是生産&測試兩用，對于運維來講等于沒有測試環境(因為大多數系統應用具備全域穿透)
（4）.研發代碼可以直接通過gitlab上生産，卻不具備復原功能，一旦出現未知bug(之前沒有檢測到的)，恢複不能做到快速簡捷
（5）.叢集架構和業務邏輯圖沒有做到實時更新，現有架構圖不能清晰展示生産&測試 應用邏輯
（6）.權限不嚴格，目前公司内部的權限很混亂，目錄結構也混亂，不能根據目錄名稱看出目錄内容
（7）. 伺服器優化不夠，伺服器上存在大量無效内容，造成伺服器的運作不是很理想
（8）.伺服器裝置配置不合理，存在相當一部分小伺服器，實用性不高
-
要改造的架構是什麼？他們的優點？
對目前架構主要改造點：
（1）.将目前測試環境剝離出線上K8S叢集
（2）.增配一套線上預發環境(縮小版生産環境)
（3）.将原叢集的網絡模式有經典公網改為專用網絡+彈性IP
優點：
（1）.提高生産環境的穩定性和安全性
（2）.使用預發環境完全模拟生産環境，提高應用上生産的靠保障性
-
改造後能給公司帶來什麼？是效率更高？更安全？還是更省錢？
改造後的叢集系統，形成，測試、預發、生産三套系統，測試線上下，預發和生産線上上，應用app 經過預發環境驗證後再上生産環境，安全性得到保障。将小伺服器更換大伺服器，既省錢又便于管理維護。
-
改造牽涉的人有多少？需不需要動代碼？
監管協助人：XXX
業務協助人：XXX
實際操作人：XXX
目前方案，确定不動代碼。
考慮優化點：
統一環境名稱： 研發 預發 生産
研發環境： 線下 供研發人員使用
預發環境： 線上 縮小版的生産環境，并且兩者環境應盡可能一緻（版本、應用等）
生産環境：線上 隻有在預發環境經過驗證的應用，且總結有相應操作步驟和故障演練的文檔才能改動生産環境。
對生産的操作嚴格要求
（1）對生産的操作應提前在預發環境完成并得到驗證(而不是線上下的研發環境)。
（2）對生産的操作要嚴格進行：公司内部通知、官網通告、預案報告
（3）對生産的操作要嚴格按照權限進行。生産的操作權限縮小到個别人。提高安全級别。
對叢集的優化
（1）. 合理設定各目錄的作用。如：
/data 目錄放資料
/var/log/xxx 放日志
/service/scripts 目錄放腳本檔案
/yaml/xxx/xxx xxx是大的方向 比如日志系統(elfk) xxx是資源檔案
（2）. 對叢集的登陸 生産環境隻能在公司辦公區域内登陸，預發環境可以公網登陸 加強對叢集的管理
（3）. 公司内部業務、叢集(業務)拓撲圖及時更新 有應用改動就更新
（4）. 加強對叢集的穩定性優化 比如：對磁盤空間進行及時清理
（5）. 網絡這塊原：經典公網ip 新：專用網絡 + 彈性IP
（6）.故障演練，每隔一段時間(半年)進行一次故障演練，可以及時有效的檢驗叢集的健壯性
操作流程規範化
生産環境：
- 每次改動要提前送出郵件進行确認
- 每次改動要形成文檔
- 每次線上上的改動要記錄下操作指令和重要資訊
- 線上的改動除緊急bug外，一律先在預發環境進行驗證
- 對cicd流程 進行切分，預發cicd，線上cd。
- 對線上環境的改動要在辦公區進行，且改動涉及到的所有人員都應該在現場。
響應等級
業務可用類故障等級表
| 等級 | 描述 | 指派 |
|---|---|---|
| 一級故障 | 業務中斷8小時 | 1 |
| 二級故障 | 業務中斷2-8小時 | 2 |
| 三級故障 | 業務中斷1-2小時，業務核心功能無法使用 | 3 |
| 四級故障 | 業務中斷1小時，業務核心功能收到影響 | 4 |
| 五級故障 | 業務中斷1小時以下，業務次要功能無法使用 | 5 |
故障響應時間表
| 故障等級 | 響應時間 | 聯系人 | 解決時間 |
|---|---|---|---|
| 一級 | 1分鐘 | XXX、XXX、XXX、XXX、XXX、XXX | 8小時 |
| 二級 | XXX、XXX、XXX、XXX | 2-8小時 | |
| 三級 | XXX、XXX、XXX | 1-2小時 | |
| 四級 | XXX、XXX | 1小時 | |
| 五級 | XXX |
架構圖優化
優化點：
1. 權限分明
2. 測試、預發、生産區分明
3. 可靠性、安全性比優化前更高
過手如登山，一步一重天