V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Coding.NET 轻量级社交
开源项目广场
使用帮助
意见反馈
CodingNET
V2EX  ›  Coding

他山之石——运维平台哪家强?

  •  
  •   CodingNET · 2019-04-10 16:08:32 +08:00 · 5003 次点击
    这是一个创建于 1814 天前的主题,其中的信息可能已经有所发展或是发生改变。

    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/sre/sre-book/chapters/part3/
    吉恩·金( Gene Kim );耶斯·亨布尔( Jez Humble );帕特里克·德布瓦( Patrick Debois );约翰·威尔斯( John Willis ).《 DevOps 实践指南》

    3 条回复    2019-04-19 10:17:41 +08:00
    mokeyjay
        1
    mokeyjay  
       2019-04-10 16:17:48 +08:00
    才发现 coding 居然有一个专门的节点……有钱真是好啊
    liuxey
        2
    liuxey  
       2019-04-10 16:19:17 +08:00
    请问 coding 现在是凉了吗?好像服务全都导向腾讯平台了
    CodingNET
        3
    CodingNET  
    OP
       2019-04-19 10:17:41 +08:00
    @liuxey 您好,腾讯云开发者平台是腾讯云与 CODING 共同为开发者打造的云端工具平台,CODING 老用户点击”登陆“可以不升级腾讯云开发者平台继续使用。
    如选择升级至腾讯云开发者平台,可获得免费、更高速、更多资源、更好体验的产品和服务。腾讯云开发者平台的使用体验与 CODING 个人版完全一致,产品和服务依然由 CODING 团队提供。
    如您在使用过程中遇到任何问题,可以随时通过官方邮箱: [email protected] 向我们反馈,谢谢。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1013 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 19:40 · PVG 03:40 · LAX 12:40 · JFK 15:40
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.