摘要：当云平台出现网络故障系统故障等问题，这对云租户用户有时甚至是致命的，所以不少是由高级别开发人员转型而来。目前国内各大云厂商也基本都提供了应用运维平台，包括腾讯蓝鲸阿里华为等。
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.net
https://landing.google.com/sr...
吉恩·金（Gene Kim）；耶斯·亨布尔（Jez Humble）；帕特里克·德布瓦（Patrick Debois）；约翰·威尔斯（John Willis）.《DevOps 实践指南》
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/8109.html
摘要：对于商业市场来说，特别是中国这样一个云计算才刚刚起步的市场。反观云计算售卖的一些商品，目前主要还是以服务器为主。云计算的本质是将计算能力转化为标准化，可售卖的服务。可以说是云计算实践的一个经典案例。有的人会问，云计算厂商需要提供哪些服务。 2015年伊始，国内云计算市场可谓风起云涌。各路群豪纷纷涌入这个市场。其中最活跃的领域当属IAAS。阿里腾讯硝烟未尽，百度重新检讨了自己的PAAS战略后，...
摘要：虽然已经成为了云领域的容器技术之王，但一个新的挑战者已经出现了。拥有一套集群来连接其他的集群服务，例如以及亚马逊的容器服务等。也对有着同样的关注，后者是谷歌的开源容器管理器。微软公司于近期实施了，这是企业应用容器技术的一个共同选择。 虽然Docker已经成为了云领域的容器技术之王，但一个新的挑战者已经出现了。专家David Linthicum针对这一竞争进行了分析。随着新的一轮竞争开始，容器...
摘要：北京时间月日月日，由和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会简称在北京国家会议中心圆满落幕。本届峰会，来自阿里美团百度平安银行等企业的讲师分别从企业转型及研发效能方面分享敏捷和的实践细节和操作经验。 北京时间11月30日-12月3日，由msup和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会（简称：TOP100summit）在北京国家会议中心圆满落幕。T...
摘要：北京时间月日月日，由和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会简称在北京国家会议中心圆满落幕。本届峰会，来自阿里美团百度平安银行等企业的讲师分别从企业转型及研发效能方面分享敏捷和的实践细节和操作经验。 北京时间11月30日-12月3日，由msup和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会（简称：TOP100summit）在北京国家会议中心圆满落幕。T...
亚马逊卖家专用vps有没有?亚马逊卖家最害怕的是什么，那就是被检测到使用同一个IP地址运营多个店铺，导致店铺被封禁的情况，而云服务器可以完美解决这种问题，至于原因为何，且听我满满道来!哪家亚马逊云主机好用呢?只要IP纯净，服务器稳定，用于亚马逊是很安全的，你可以百度搜索易探云，这家是专业的海外运营云服务器商家，同时推出美国电商云，保证IP纯净～搞亚马逊运营店铺，云服务器是绝佳选择，而易探云优惠力度...
阅读 1226·2021-09-02 09:53
阅读 2558·2021-07-29 13:50
阅读 1536·2019-08-30 11:07
阅读 1483·2019-08-30 11:00
阅读 1335·2019-08-29 14:00
阅读 1703·2019-08-29 12:52
阅读 2441·2019-08-29 11:11
阅读 3308·2019-08-26 12:23
