DevOps学习笔记

Posted 2021-04-16 愚人老黄

《愚人老黄》

传播：项目管理 | 网络安全 | 数据治理  | 瞎扯淡

点击蓝字

 

DevOps的起源

都信息时代了，各行各业自然也就离不开各类软件系统了，无论是微信支付宝还是看病挂号，打车住店，你能说出来的业务都信息化了或者在信息化的建设路上。一套软件系统要想用的好，就需要软件开发者和运行维护人员以及维保开发人员通力合作。近年来DevOps这个概念开始流行起来，所谓开发运维结合模式，就是把软件开发和运行维护结合起来的工作模式。它通过传递一种分享文化、协作文化和精益文化，促进团队协作，从而不断生产出更好的产品，提供更优质的服务。

它是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

DevOps的发展

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。核心还是想通过推行和倡导一种协作的文化，让用户满意，进而提升产品的竞争力。其实好产品不仅是需要内部的协调，很多时候还需要去培育客户，改变客户使用习惯，进而才能把产品做好。比如大家熟知的打车软件的最初的烧钱推广模式，就是一种客户习惯的培养。

为什么会出现DevOps，这也是得从软件工程行业发展谈起，最初的软件开发就是一个人的工作，从了解需求到架构设计再到程序开发以及系统维护，大牛们就是一个人搞定，比如说大牛求伯君，一人之力搞出个WPS。但是他这种模式是难以复制的，个人开发带来的就是效率问题，它类似于我们的家庭作坊和原始农耕模式，内部无需沟通，但是生产效率就不高，不适合大规模生产。

随着软件行业深入发展，开发的系统越来越大，逐渐出现了分工，有负责UI的，有负责架构的，有负责数据存储的，还有负责功能的。在技术上需要学习更多的东西，借鉴工业管理的经验，慢慢的软件开发也进行了细分，开启了团队作战的模式。

在商业应用过程中，逐渐又派生出运维工程师、研发工程师、售前工程师等岗位。售前工程师负责讲解及展示产品性能，收集用户需求；研发工程师负责开发产品，修正产品漏洞；运维工程师负责处理系统运行中出现的问题，反馈改进意见给开发人员。

DevOps是一种文化，不是角色！

目光转回到医疗行业，对于我们多数医疗机构来说，应用软件以购买为主，为了保障应用系统的稳定运行，信息科应运而生，信息科工程师承担起了运维工程师的职责。但是，对于这种商业软件功能的完善，代码错误的修改，信息科却是无能为力的，就只有购买维保服务了。

没有一家软件公司的产品是完美的，也就没有一家软件公司的产品不受到用户的诟病。尤其是在这风云激荡的医改十年，各种政策法规的调整，使得医院的管理和业务也在发生着众多变化。政策变，制度变，则软件也要跟着变。

变变变，钱钱钱，为了适应新需求，信息科就成了一个讨人嫌的孩子，就知道要钱；而很多时候要来钱，上了系统也不见得就得到了用户的认同，系统需要修改；改改改，让软件公司不厌其烦，对的要你改，不对的也要你改，美其名曰个性化需求。经常听到的抱怨就是“信息科不行，软件公司不行”。

我一直在思考一个问题，那就是为什么“军字一号”系统能够取得如此大的成功。在学习了DevOps的相关知识后，发现军字一号在这么多年的运行过程中，一直奉行的不就是这种工作模式么。

DevOps成熟度评判指标

在“军字一号”的运营模式下，医院信息科工程师承担系统的运维，收集反馈问题，也可进行部分功能的开发及改造；总后信息中心的工程师承担着系统的开发工作；信息中心在每次系统变更时，常规组织培训和讲座，以及新技术的培训，用句时髦的话，就是赋能医院信息科。这些做法也保证了军字一号系统在各级各类军队医院稳定运行。

当年我们还是HIS小白时，总后信息中心就定期组织培训，以提升我们的工作能力。印象最深的就是到301医院，由薛万国主任，刘敏超主任（当年还是一枚小鲜肉）给大家上课，手把手的教大家编程，架构，数据库。每个工程师也是热情高涨，都是机房、食堂、宿舍三点一线的高速运转。

系统上线后，郭歌、李国宝、吕雪峰等大神坐镇总部，有什么问题大家都是不厌其烦的听取意见，定时进行新版本发布，新功能的完善，后来又很好的利用了远程会议平台来举办各种上线前培训。这种伴随系统全周期的赋能服务，也是让军字一号这么多年健康稳定运行不可缺少的重要因素。

反观现在一些IT公司，研发，运维，售前各岗位之间反而有很深鸿沟。售前为做成生意，什么牛皮都敢吹；老板为了利润，不断的压缩成本；研发为了赶工赶进度，漏洞频出；质量管理，测试也不完整，经常上线就是掉线，升级就得宕机；运维也是把自己定位在得过且过，只是传送带和受气筒。结果就是产品在线，口碑掉线，各岗位互相推诿，用户怨声载道。

DevOps实践之我见

DevOps实践架构

以我这些年做运维工作的经验，结合DevOps的学习（一个熟悉的做法，全新的名词），通过对以下关键环节的把控是可以提升软件水平和服务能力的。

1、代码管理，很多公司对代码管理非常头痛，尤其是客户多了，版本就乱，一次升级就成了一场灾难，因此，代码管理确实非常重要。

2、项目进展管理，时间、成本和质量是项目管理的三要素，作为项目经理必须做好平衡。也需要协调好甲乙方资源，推进项目的完成。

3、问题管理，要常规运用事故管理的模式，对问题进行根源分析，提出改进意见。这里用好PDCA，RCA这些管理工具，非常有必要。

4、系统架构的稳定，架构不是一成不变的，也不应有普世标准。我们看《淘宝十年》就会发现，在不同时期，不同的体量规模下，淘宝的技术架构也在不断调整，稳定中的迭代发展是必由之路。但无论是什么时期，一个稳定可拓展的架构会让系统运维起来更顺利，体验更好。

5、测试问题，不说啥黑盒白盒测试了，反正我觉得测试这个环节做的蛮不好的，我们用的软件不说进行漏洞测试了，就是一些错误都是上线了再去发现。比较欣慰的是，医疗信息化软件未来可能会作为医疗器械进行管理了，这样一来，一定会提升行业对测试工作的重视程度了。

6、知识积累及传递，一个公司一个部门多年的实践经验的总结，这些总结需要靠时间的积累，在经验和教训的积累下慢慢沉淀。当你拥有了丰富的行业知识，你也就成了老油条了。一个团队需要从老油条身上提炼出老油来，这样对于公司和单位的能力提升都很有好处。小鲜肉一抹此油，容光焕发呀。

7、运维前端可配置，与用户接触最紧密的就是我们的运维工程师，用户对他提出的需求也最多，系统的灵活性体现在他能运用何种工具对所管理的系统进行客户化配置，以适应客户的大量且多样的需求。如果运维工程师啥都干不了，不但影响公司形象，也会大大拉低研发工程师的效率。

8、性能监督和度量，监督和度量能够让我们了解系统的瓶颈和改变方向，尤其是利用一些锚点设置，更能了解用户的习惯，促进用户画像数据的产生，从而做到比用户更了解他自己，做出更好的产品。

9、团队建设构建协作共进的IT文化，协作共赢，相互信任是DevOps的初衷和追求目标。而要达成这个目标，就需要培养团队成员之间的认同感。这种认同感不仅是在工作中产生，也需要通过文化进行熏陶和培养。

10、采用必要的自动化管理工具，很多新的工具确实是当年没有的，一些新技术的运用，也让当年的一些模式和方法需要改进。自动化的工具会让我们工作更有效率，沟通更顺畅。

---

林林总总写了很多，这也仅是我初次接触这个方法的一些思考和体会，不一定对，也希望朋友们能帮我指出错误。

○

愚人老黄

○

项目管理 | 网络安全 | 数据治理  | 瞎扯淡

欢迎关注、欢迎分享、一起学习、共同进步