可灰度
可監控可應急
禁止在非變更視窗期、封網期進行變更（不同的公司變更期不通，基本都有高峰期/低峰期的規定）；這些變更包括但不限於：壓測，**提交到生成，緊急線上變更需要走審批流程。
禁止未經測試驗證， 預發驗證，或者灰度的線上變更
禁止無邊跟影面、操作步驟、驗證方案、應急預案及回滾方案說明的變更，應急預案必須具備可操作性，通俗的講就是：任何變更都必須評估風險，做好sop，做好操作失敗的修復方案。
禁止一切變更方案外的操作，如果變更出現非預期的情況應當立即停止並將情況反饋到上級，不要做額外的操作試圖來改變些什麼，這中額外操作可能帶來更大的不可控的影響。如果需要調整方案，需得到上級的批准，且走了緊急變更流程。
禁止在生產環境執行或變更與線上問題排查無關的操作
說明：所有的系統都應該接風控平台，做到任何變更有記錄，有據可循。觸發變更紅線的判定，也以系統日誌為準。
灰度必須為有效灰度，灰度比例包括但不限於地區、使用者、裝置、集群、機房。有線上有效流量，灰度時間不小於10分鐘。變更期必須盯著監控面板，事後必須線上驗證，有異常第一時間會滾
線上變更指：對線上的任何操作，包括應用系統發布，系統調整，後台配置，資料結構變更，資料訂正以及規則策略調整等一切線上變更操作。
只有紅線，卻沒有觸發紅線的處罰措施也是不行的，這就如同有了監控系統卻沒有報警系統一樣，監控便成了擺設，發揮不出其價值。當然了，紅線問責，也是為了提醒大家不要觸碰紅線，並非以處罰為目的。
問責，根據不同公司的規章制度進行問責，通常的做法是和和績效，晉公升關聯。
一次違反變更紅線並引發故障的責任人，半年績效不合格，並在技術團隊範圍通報
二次違反變更紅線並引發故障的責任人，全年績效不合格，並在技術團隊範圍通報
一些重要的活動，**等期間產生的故障（不論大小，包括冒煙），都按照1，2處理。
違反紅線變更，並對公司產生較大利益損害以及**壓力的，可酌情勸退。
如果乙個團隊連續出現違規變更，觸發紅線，那麼管理者也當一併問責。
每次違反紅線的責任人，其主管連帶問責嚴重警告一次，並且技術團隊範圍通報；如果主管受到2次嚴重警告，那麼半年績效不合格
新人試用期內，實習生觸發的觸發規則的，由直接主管代為承擔處罰
基線變更與非基線變更
一 基線變更 一 變更申請 專案經理或變更申請人填寫 軟體變更申請表 說明要變更的內容 變更的原因 受變更影響的關聯配置項 工作量 變更實施人等，並提交給ccb。二 變更評估 ccb組長負責組織對基線變更申請進行評估。變更的內容是否合理 變更的範圍是否正確 考慮周全 工作 量估計是否合理 基線變更的...
發生線上故障後問責是不是第一要務
google sre 這本書，說過這樣一句話 系統正常，只是該系統無數異常情況下的一種特例。故障是不可避免的，不管是再牛的系統 再知名的科技公司。既然不可避免，我們要做的就是不斷提公升能力和優化流程，減少故障出現的概率。今天公司線上系統出現了響應遲鈍的情況，白天偶現，到了晚上，出現雪崩效應。各個系統...
EMC首席資料治理官 「受託人」是資料湖問責的關鍵
據emc公司自己的首席資料治理官barbara latulippe稱，今天的首席資料官 cdo 想要成功的話就需要得到高階管理層的認可和接受。今年在美國麻省理工學院舉行的首席資料官cdo論壇上，latulippe分享了促進資料所有權和資料訪問的最佳實踐，以及emc在資料湖方面嘗試的方法。治理當前的資...