因为有看到一些关键字，还是单独回一篇好了。 ※ 引述《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/cn.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/cn.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