因為有看到一些關鍵字，還是單獨回一篇好了。 ※ 引述《walker088 (巴拉圭魯蛇)》之銘言： : 各位年薪百萬大大們好 : 小魯我是目前在巴拉圭的替代役男 : 剛開始在地球另一端摳頂大概三週而已 : 工作的計畫是協助他們國家醫院醫療資訊系統的開發&維護 : 使用的技術如下： : Backend: Java 8, Struts2, Tomcat 8.5 [-----] struts 2 必須死 http://bit.ly/2HYz8vB : Database: PostgreSQL-9.4 : Platform: CentOS 7 : Others: Flyway, Gradle : 這邊想跟各位大大請益問有關DevOps的問題 : 這裡開始使用我們系統的醫院目前都有獨立的伺服器 : 因此當我們的APP(Java)或DB有做修改後 : 他們目前是逐台Server做手動更新 : 滿浪費時間的而且未來推廣到更大量醫院時候很慘 : 幾分鐘前老闆讓我找個方法可以同時更新所有的Server 這段配合著你在推文中想的情境來看 『 量很大且人力不足的話 (e.g.,300台機器 5人的team) 也會是傾向逐台手動嗎? 不會是像MS那樣直接更新? 』 假設，程式真的寫得糟糕到不行。 每 1 台只能同時有 100 人在 web 上操作。 那你是打算要同時服務 3 萬人嗎？ 這例子其實不太合理，但也是那是你因為焦慮而隨意說說的內容。 真的到你得服務麼多人時，早不是這樣的架構了。 (團隊編制應該也很不同) : 這邊因為基本上更新主要有兩個任務： : 1. 寫好更新DB的sql後丟上Server用Flyway執行 (或直接psql吃.sql) : 2. 開發出新的版本後包成 .war 檔丟進Server的Tomcat 由於你才剛進入團隊 3 週，也許別急著要做出成果來。 先別管 DevOps 是什麼東東， 你目前在做的事情本質上是自動化部署 (還談不上 CI/CD 的邊，因為有些基礎建設並不存在) 依你的方法是可行的，BUT.... : ----------------------以下是土法煉鋼-------------------------- : 目前直覺想到的解法是寫個簡單的輕量TCP Server放在醫院們的Server上 : 接受可以通過一些檢查(e.g., rsa)的TCP client的請求後執行上面兩個更新的動作 : -------------------------煉鋼完畢----------------------------- 我們可以隨意挑出幾個目前廣泛運用在 DevOps 或 CI/CD 工具 來做到你想要做的事，但輕易地跟你說 『 OOO 可以做到你想做的 XXX 』 是個便宜的答案，你可以暫時間內獲得能動的解答。 但對大家都沒有益處，因為基礎建設不足可能引發的災難遠大於效益。 自動化的優點就是省去人工的時間， 並且它會非常地快速完工 (相較於人類的手速來說) 若沒有基本的 CI (也可能沒有能跑的 test case) 那麼 Bug 或程式缺陷也會被迅速地部署上去。 到時你想喊停可能都還來不及啊！ 這就是為什麼，我的推文是問『災難回復』的策略與演練呢？ 你們團隊的 plan 是什麼？有沒有 plan 來幾個小問題就能先心裡有個底了 先試著回答一些簡單地問題: 1. 如果所有的 server 與 db，不小心因為天災、人禍而消失 有辦法輕易地重建回來嗎？ 2. 有定期備份 db 資料嗎？上一次備份的時間是什麼時候？ 3. 有定期試著由備份的 db 資料，做回復並驗證內容的正確性嗎？ 4. 在基礎系統設定完成後 (像是基本的 OS, Network, Account) 4.1 安裝 db 到資料回存完要多久時間？ (別忘了算取回備份的時間) 4.2 安裝相關 server 並佈署完應用程式，能開始對使用者服務要多久 4.3 整個 4 是否有『計劃』並完整理處理過一輪 5. 上述的每一項目是否有 RCA 的 log 記錄，不管是專門的文件或 issue 內 供後人做 trouble shooting 的參考 你的回答有幾種可能： 1. 集合團隊所有人『腦中』的智慧有辦法完成上面的每一件事 2. 已有文件來回答上面的每一項問題（或部分的問題） 2.1 通常是有 4 的文件，但其他項目不清楚 2.2 假設有文件，但可能 out of date 已久， 它可能是先前剛建 team 時寫下來的，但後來忙於日常開發就不再更新 3. 針對 server 環境的初始化已有 provision 腳本 (例如寫成 ansible playbook) (你絕不會想要反覆地去搞 CentOS 的 selinux 設定的， 或程式跑一陣子發現 ulimit 忘了改，而開不出檔案) 4. 針對應用程式 deployment 已使用自動化工具 (例如寫成 ansible playbook) 5. 不僅自動化了應用程式部署，並在那之前 release 版本皆通過足夠的測試 5.1 基本的單元測試 5.2 配合外部環境的整合測試 5.3 針對使用者視角的 e2e 測試 ................................................ 雖然是說問幾個簡單的問題，不知不覺就寫了許多 (汗 : 但因為並不熟悉Dev-Ops的領域 : 怕這樣土法煉鋼未來會比較麻煩 : 畢竟役期只有接近一年，結束後就會返台了 一年其實不短，真正該導入的不是 tool 而是 mindset 當 mindset 對了，要挑什麼工具只是依情境判斷的問題。 先前的題問，其實還在開發階段的事情，還沒提到維運部的事。 monitoring 又是另一個重要的主題，假設你真的有 300 台!? 你真的會想一台一台上去看 log 或看誰硬碟滿了要清嗎!? : 為了避免留下困擾給之後的人 : 想詢問是否有比較主流 or 有制度 or未來好管理擴充的做法 : 有開源工具或者相關關鍵字的話就更好不過了！ : 感恩感恩 Continuous Delivery https://amzn.to/2KcrjUy http://bit.ly/2K8o14y Effective DevOps https://amzn.to/2K8ouDQ http://bit.ly/2KaETI6 想起先前也有回過類似的主題 https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1475483798.A.9C0.html 另外，關於 Tomcat 有個實用的功能 Parallel deployment http://bit.ly/2KaP3bD 可以針對同 1 個 context 部署多個版本，利用它來達成 zero downtime deployment 很好用。 然後，如果程式碼不多， 或能切出新功能是用不同的 tech stack 的話 struts 必須死！ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.141.56 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1542462776.A.040.html ※ 編輯: qrtt1 (36.231.141.56), 11/17/2018 22:21:00 偏鄉的小公司 (咦!? ※ 編輯: qrtt1 (36.231.141.56), 11/17/2018 22:36:27