DevOps 全链路
下图是我们熟知的软件研发环节,在迭代频率高的研发组织里,一天可能要经历多次如下循环。对于用户群体庞大或者正在经历大幅业务扩张的企业研发组织,除了重点关注应用的快速上线之外,如何保障应用的高可靠、高可用也成为焦点,即服务上线要快,运行要好。
如何让开发更简单,运行更高效,接下来我们从两个角度来探讨这个问题:
组织方式
研发工具
关于运维人员的组织方式
一种方式是组建专门的运维团队,一个运维团队往往会承接多个开发团队的协作。除了 DBA 这类针对某个中间件的运维之外,这种模式的弊端在于不少运维工程师深陷于环境配置、日志收集、业务恢复、现象记录等琐碎事情当中,没有时间阅读项目源码以及提升能力,对较为深入的业务问题分析困难,开发团队又往往无暇分身,运维容易陷入被动的境地。
另一种方式,开发人同时负责各自模块的开发与运维。好处自然是由于开发人员熟悉本模块源码,定位问题的效率要高出不少。同时开发者可以直接得到下游用户使用反馈,将其融入到研发当中去。坏处在于,让开发人员陷入到频繁的用户问题定位之后,难以保证代码开发的时间。
近年来,国内也兴起了 SRE 这种高级运维职业,特别是在云计算行业,SRE 的职业要求非常高,需要精通诸如网络、编程、算法、数据结构、操作系统、安全等知识与技能。当云平台出现网络故障、系统故障等问题,这对云租户 / 用户有时甚至是致命的,所以不少 SRE 是由高级别开发人员转型而来。
在 Google SRE 的服务可靠性层级当中,SRE 通过产品、开发、容量规划、测试、根因分析、事件响应、监控七个层次的实践来确保应用服务的健康状态。从这个层级当中我们可以看出 Google 提倡运维要积极控制服务发展的方向,而不仅仅在事故发生后反应性地灭火。目前来看,SRE 这种精英式的运维在国内还有待探索与实践。
粗暴地将开发运维拆开,或者将开发运维简单合并,都不是特别合适的一种方式。从笔者的研发经验看,一种方式可供大家思考与讨论——根据业务实际情况做分工:比如由团队内的开发者轮流负责整个项目运维。由于各个开发者对项目公共代码都需要熟悉,在理解其它模块代码也相对快速,这种方式基本能消灭大部分的问题,剩下的一小部分可以和指定模块的负责人结对定位。除此之外,为“每个服务团队分派运维联络人”,“邀请运维工程师参加开发团队的会议”都是能够加强运维与开发之间协作的措施。
关于工具的使用
除了恰当的人员组织方式之外,合适的工具也能给研发团队注入能力。
在配置研发环境时,研发组织可以选择通过开源工具自建代码管理和持续构建环境。这种方式的缺点在于需要有专门的 CI 团队来维护持续构建环境,一旦环境被破坏,开发的脚步就会停滞。并且由于各个开源工具数据未打通,开发人员要在多个工具之间切换使用。另外一种方式就可以通过现有的软件研发管理系统,例如 CODING 研发管理系统,来实现一站式的研发流程管理,无需自建、维护众多的研发工具与研发环境,支持在浏览器中完成全套软件开发流程,真正做到了 Coding Anytime Anywhere。
当开发人员通过 CODING 研发管理系统快速开发并部署好应用后,下一步就要让应用在运维工具的辅助监控下可靠运行(并不是所有应用都需要运维工具,需对症下药)。研发组织可以选择自己开发运维工具,也可以选择现有的运维工具。
目前的运维工具逐渐地朝以应用为中心发展,因为应用是直接向用户提供业务能力的,无论是开发还是运维,都是被业务价值驱动的。主流的运维工具主要涵盖基础设施层监控、应用层面监控、业务层面的分析与监控。
接下来我们看看现有的运维工具一般会提供哪些具体能力:
基础设施环境的监控:对服务器整体的 CPU、内存、磁盘、文件系统、网络等资源占用情况进行上报。
应用性能监控:针对应用使用的中间件,例如持久化数据库、缓存数据库、消息中间件等访问效率进行监控;以及对应用本身请求响应速度进行监控,包括延迟、吞吐量等等。
应用调用链路追踪:在分布式系统下,一个请求往往需要经过多个进程处理完毕。当出现用户请求调用失败或者出错时,运维平台支持整个调用链路的分析与故障环节定位。
日志数据采集与分析:日志的采集主要是为了辅助应用调用链路分析以及性能监控,运维人员无需进入后台去大量翻找日志。
故障自动恢复
灵活的告警
可视化面板展示监控与告警信息
国外热度较高的运维工具包括 ZIPKIN(分布式追踪),pinpoint(分布式追踪),logstash(数据收集)等等。目前国内各大云厂商也基本都提供了应用运维平台,包括腾讯蓝鲸、阿里 ARMS、华为 APM 等。以下是这几个运维平台能力的简要对比:
目前大部分的运维平台主要通过 Agent 和探针的方式去采集应用的指标信息,汇总处理后反应在可视化界面上。除上述的工具和平台之外,AIOps 也逐渐成为未来的一个趋势,AIOps 通过 AI 技术的运用来进行智能业务故障诊断,同时自动恢复应用故障,企图让研发组织彻底告别人肉运维时代,笔者也万分期待这天的到来。运维人员不用担心因 AIOps 失业,工具和平台只是提升运维效率,不会取代运维。
在运维阶段发现缺陷后,开发人员可在 CODING 中处理对应的缺陷,记录下每个缺陷的类型、优先级、模块、描述、处理人等信息。软件缺陷是不可避免的,但只有通过对缺陷进行管理和复盘才能知道缺陷产生的原因(人为因素 / 环境因素 / 工具问题等),从而改进,避免类似缺陷的重复。对缺陷的管理也有助于管理人员对软件质量的正确评估。缺陷处理人通过 CODING 实现缺陷的快速修复和部署,可大大缩短故障恢复时间,减少因缺陷产生的业务损失。
在 DevOps 理念的指导下,笔者建议开发人员在开发业务代码时,除了功能之外,也应当思考如何开发可运维的代码,通过适当的日志、错误码、异常等措施来提升运维效率;运维人员也需逐步提升能力,从传统的繁杂运维当中转型,走上敏捷自动化的运维之路。
写在最后
我们可以看到随着 DevOps 工具链自动化显著提升,DevOps 的门槛变得更加地低。拥抱自动化的结果是研发过程会变得越来越安静,顶尖的开源项目里的 committers 在日常仅仅是通过邮件和 issue 将事情说清楚,没有热火朝天、冗长拖沓的会议;也没有花花绿绿,色彩斑斓的工作表格。但这些都是建立在 DevOps 良好实践的基础之上。我们相信在践行 DevOps 的道路上,未来软件的开发会更简单,运行也会更加高效。
参考:https://www.collab.nethttps://landing.google.com/sr… 吉恩·金(Gene Kim);耶斯·亨布尔(Jez Humble);帕特里克·德布瓦(Patrick Debois);约翰·威尔斯(John Willis).《DevOps 实践指南》