Devops系列
為什麼需要開發運維
開發運維可以創造巨大競爭優勢，讓產品可以快速進入市場，提升客戶滿意度、市佔率、員工生產力和幸福滿，能讓企業取得勝利。
原因：科技變成主要價值創造流程，變成開發客戶與維繫客戶的主要手段，重要性越來越高。
從表上耗時幾週或幾個月來部屬，處於相較於不利位子上。
註記：很多公司在部屬上還是用手動部屬上版居多，有發佈到正式機的人會很清楚就會知道，假設公司假設API有八台Server正式機，通常上版都要從master拉下來到編譯至發佈到Production的環境中，每一台SERVER都要上版，其實滿容易出錯的...若是系統很多，上版的人其實還滿累的...
採用開發運維原則
績效部分
- 程式碼部屬頻率快30倍
- 程式碼前置時間快8,000倍
可靠性
- 變更成功率2倍
- 平均修復時間快12倍
三步工作法
The First Way：關乎從開發到運維再到客戶，從左而右的工作流。
主要是為了讓流量最大化，需要【小】的批次規模與【短】的工作區隔，絕對不讓陷流向下游工作中心，而且為了讓整體性目標持續最佳化(相較於局部性目標，諸如開發功能完成率、測試發現率/修復率或者運維有效性指標。
必要的實務：作為連續建置、整合與部屬、所需建立環境，監控在製品及建構能夠安全進行變更的系統及組織。
The Second Way：關於在價值流各個階段中，由右至左持續流動快速回饋，放大效益，確保防止問題再次發生，或者更快速發現與修復問題，在需要的地方建立或融入知識，從源頭確保品質。
必要的實務：建置與測試在部屬管道中發生失敗時，【停止生產線】；每天持續改善日常工作；建立快速的自動化測試組，確保程式碼處於可部屬狀態；在開發與IT運維之間建立共同目標與同甘共苦的文化；建立普遍性的產品遙測機制，每個人都能看到程式碼和環境是否按照設計進行，是否達到客戶目標。
The Third Way：關於創造公司的文化，形成兩種風氣持續不斷的實驗，這需要承擔風險，從成功和失敗中吸取經驗教育，體認反覆和練習是達成精通的基本前提。
實驗與承擔風險是為了能夠持續改善工作系統，採用一些過去大不相同做法，一旦出問題，不斷反覆與日常操演便能提供足夠技能與經驗，回復到安全區域並正常運作。
必要的實務：建立創新、勇於冒險、高度信任文化，把至少20%的開發和IT運維周期分配給非功能需求，持續強化鼓勵與進行改善活動。
註記：看到第三點筆者認為是相當困難的一部分，而是要從自身去培養起當責的能力，平常就要勇於自我反思與透過別人的反饋找出自己的盲點，這部分是來自豐田生產的精神，自我成長與持續改善的能力和最重要的是培養自己思考與自己行動的能力，再來豐田生產的方式是而是要用腳、手到現場去，與企業主、作業者一起觀察、思考、實驗，理出大家能接受的方法。
IT專案分成四大類
- 業務專案
- IT內部專案
- 變更
- 計畫外工作或救火工作
業務專案
大多數開發專案處理的業務專案，屬於公司業務發展所需的專案。
IT內部專案
由業務專案延伸出來的基礎架構貨運維專案，內部改善專案之類(建立新環境與自動化部屬)，專案來自集中管理，通常預算屬於DBA，或是IT相關部門經理。
當IT開發運維遇到瓶頸時，會產生問題，因為沒辦法查出在內部專案花了多少生產力。
變更
通常上述兩種專案工作所引起，必須透過工單系統(EX:JIRA或IT運維補救措施，用於開發敏捷計畫工具)。
計畫外工作或救火工作
工作運維的事故由上述三項工作所導致，往往犧牲其他計畫內工作為代價。
後續待補...
元哥的筆記
