作者：平静静 来源：微信公众号【汪子熙】
原文链接：https://mp.weixin.qq.com/s/dcXZBwaVLZpYTHH4oN8wlw
今天的文章来自我的同事平静静，SAP成都研究院一位程序媛。平静静2010年加入SAP，熟悉她的人一般都叫她平静。在她待过的每个小组，平静静都不是最引人瞩目的开发人员，然而她总是能一如既往，保质保量地完成开发任务，为团队默默地做出自己的贡献。
Jerry和平静静曾经在同一开发小组里共事过三年多的时间。2013年时，我们所在的CRM开发团队曾一起努力，将Twitter, Facebook和新浪微博等社交媒体的支持添加到CRM呼叫中心中去。令Jerry至今记忆犹新的是 ，早在2013年9月，平静静就开始使用Selenium进行SAP CRM WebUI的自动化测试用例开发，并且是当时SAP成都研究院最早使用Git进行源码管理的同事之一，比2014年成都团队大规模从ABAP技术栈切换到Java技术栈上整整早了一年。Jerry对于Selenimu的学习最早也是从阅读平静静的代码开始的。当时的CRM团队也是SAP成都研究院最早开始实践探索性测试( Exploratory Test )的团队，而平静静就是当时的主要组织者。
今天平静静要介绍的DevOps Enginner，有些朋友对这个词可能不太熟悉。其实就在前几天，准确地说是2018年6月27日，Jerry的朋友圈被一条新闻刷屏了。
6月27日下午，阿里云出现重大技术故障，故障于北京时间2018年6月27日， 16：21左右开始，16：50分开始陆续恢复 。阿里云官方给出的故障时间大概持续了30分钟，陆续恢复时间有一个小时多。
6月27日凌晨时分，阿里云发布了该故障原因的官方说明：“ 我们在运维上的一个操作失误，导致一些客户访问阿里云官网控制台和使用部分产品功能出现问题。 ”
该官方声明提到的“触发了一个未知bug”，具体是什么bug？
“具体原因是一个核心的应用在拉VIP列表的时候，返回了空列表，这就会导致上千VIP被禁用了 。VIP = Virtual IP Address，虚拟IP地址，主要作用为集群的负载均衡的入口地址，可通过一个VIP的地址，实现一组业务的访问，通常也叫集群负载均衡技术。VIP是集群业务的入口，如果数千个VIP被禁用了，可能后端上万台的服务、应用、数据库等将直接无法访问，本次故障盲点，是测试通过了，在生产环境触发了一个未知bug，导致核心应用在拉取VIP列表时，为空了，导致内部的上千台负载均衡不可用，从而后端的应用也不可达。”
对于这个重大技术故障发生之后阿里云运维团队的处理速度，业界还是给予了很高的评价：
"对于大型互联网公司，运维技术架构都是多层机构。 在内部负载均衡上配置的VIP如果不可达的话，后端的service层和数据库等内容，都是不可达的，这也是为什么故障的时候，页面能打开，但是报错为502故障，502错误一般常为后端服务器不可用，这也说明了故障的根源所在。阿里的运维团队故障响应还是比较给力的，数千个VIP配置错误，在半小时内从发现，到定位，到故障排除，以及解决，还是挺快的。”
说完了阿里云，言归正传，让我们来了解SAP成都研究院的DevOps吧。
下面是平静静的正文。
大家好，我是平静静，过去的一年我在SAP成都研究院Customer Engagement Center团队担任DevOps Engineer 。您一定听说过Development Engineer ( 开发工程师 ) ，也听说过 Operation Engineer ( 运维工程师 ) ，那 DevOps Engineer 是个什么工种？想回答这个问题，在我担任 DevOps Engineer 这短短的一年看来，其实既有只缘身在此山中的困惑，也有不足为外人道的窘迫。
文章目录
DevOps in SAP
DevOps in SAP Customer Engagement Center
DevOps Engineer到底要干些什么？
DevOps Engineer的一天，大概是什么样的？
现在就让我梳理一下自己对 DevOps 的粗浅认识和感受。如果您对 DevOps 的话题感兴趣，恰好身边也有 DevOps 小伙伴，不妨也跟他们聊聊。
DevOps in SAP
早些年 SAP 的产品大多是开发周期较长的On- Premise 产品，比如 ERP ， CRM 。SAP除了开发团队，还有一个专门负责产品维护的部门,名叫 IMS 。那时候的模式是开发团队完成开发之后，就可以妥妥地移交给 IMS 团队。一年之后新的版本发布，再继续 移交 。任何客户的问题如果SAP Primary Support解决不了，那么都是交给 IMS 团队处理，开发团队可以很大程度上心无旁骛地继续做下一阶段的开发。
2015 年左右，随着公司的战略转型，一系列基于云的新产品推出，SAP开发团队也在不断追求没有最短只有更短的交付时间。 1 年， 3 个月， 1 个月， 2 周。。。试想一下，原来那套基于On-Premise的开发和维护的模式是不是就搞不定了？也许 IMS 团队的同学会跳出来说，容我们缓缓，上周 移交 给我们的东东我们还没处理完 bug 呢，这周又来这么多新 功能， 实在是 Hold 不住了。。。另一方面 ，SAP开发团队也想了解，产品做得到底怎么样，应该怎样迭代得更好呢？但是隔着 SAP Primary Support 以及 IMS 团队 ， 离客户这么远，信息从何而来呢？
不只是 SAP 一家公司在思考。 战略转型，也就意味着组织结构需要做出必要的调整。 国内外的很多软件公司都在寻求新的产品开发和维护模式，使得各个团队之间减少时间损耗，从而更加高效地协同工作。如果开发和维护不再是界线分明的两个团队，而是由一个团队同时Hold 住开发和维护，是否可行呢？
借用维基百科中关于DevOps的定义：
DevOps（Development和Operations的组合词）是一种重视软件开发人员（Dev）和IT运维技术人员（Ops）之间沟通合作的文化、运动或惯例。透过自动化软件交付和架构变更的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
https://zh.wikipedia.org/wiki/DevOps
DevOps in SAP Customer Engagement Center
关于 DevOps 理念在一个团队中如何落地，细分一下，大致有：
开发即维护：每个小伙伴都既是开发，也是维护，不分工;
开发和维护：团队中一部分小伙伴是开发，另一部分是维护，分工明确;
一半开发，一半维护：团队中的维护工作由开发小伙伴们来定期轮岗。
第一种策略最贴近 DevOps 的理念。第二种策略最接近传统，第三种策略折衷。没有孰优孰劣，合适的才是最好的。要考虑的因素既要保证产品的 交付 ，同时兼顾团队小伙伴们自己的职业兴趣点和 专长 ，以及沟通成本。
SAP成都Customer Engagement Center 团队最初在转型 DevOps 时，采用第三种方式，由开发的同学每两周轮一次岗。每位同学在轮岗 的两个星期中， 50% 的 精力 用来做开发，另外的 50%精力 用来处理 DevOps 相关的 任务 。在运行一段时间之后，收到的反馈认为，虽然仍有 50%精力 做开发，但会影响 大家做事的专注力 ，整体效率不是太高。同时，有时轮岗的交接做得不到位会导致后续要花更多的成本在了解问题的上下文和 跟踪 问题上。
成都团队在之后的运行中调整为了第二种方式，虽然更接近传统方式，但弥补了方式三的短板。
DevOps Engineer 到底要干些什么？
DevOps Engineer 是指 DevOps 的模式下，身兼开发和维护的 Engineer 。当然在现实生活中， DevOps Engineer 并不一定跟Developer 承担同样的开发工作。那么 DevOps Engineer 在他/她们的小角落里都在做些什么呢？
DevOps ，就像这个词的构成方式，是 Development 和 Operation 的组合，那么一千个组就可能有一千种组合方式。这取决于DevOps Engineer 的 资源 ，以及团队目前所处的阶段。
就SAP成都 Customer Engagement Center 团队而言，团队目前处于已发版，有客户的状态。这意味着可能会有客户报过来的 ticket ，以及来自售前团队以及内部 产品经理 团队的 demo 需求，也可能会有更多的内部 ticket 以及 tenant setup 的要求。因此 DevOps同学会投入更多精力在 Operation 方面，其实也就是下图中的客户生命周期（ Customer Life cycle） 方面。
再比如，如果团队处于开发阶段，未发版，那么来自于 客户生命周期 方面的 任务 不多，可以更多地关注 CI/CD（持续集成 / 持续交付） 以及监控等环节了。
在有更多的 资源的 情况下， DevOps 同学就可以 专注于 偏 dev 方向的 话题上 ，比如客户系统的自动化创建， cloud reporting 等等。
从客户签单的那一刻起，就进入了客户生命周期管理：首先是客户系统的配置，测试，将系统交付给客户使用；其次是支持客户在使用系统过程中遇到的各种问题；再到客户系统的升级，以及可能的迁移等。这一系列活动都是直接跟客户生命周期管理相关的。
那么，怎样保障客户在使用云产品的过程中能够达到合同中所约定的服务品质（SLA：Service-Level Agreement）呢？是不是代码的质量足够好就可以了呢？当然，代码质量好肯定是产品的重要保证，但不同于On-Premise产品之处在于，云产品有更多的不确定性，也就更加需要监控工具的辅助。
首先，采用微服务架构的产品需要考虑部署在云上的服务是否可达。打个比方，如果部署在云上的服务处于 stop 的状态，那么客户的系统肯定是无法正常工作的。为了了解云上的服务是否还“活” 着，可以使用 availability check （ SAP 内部工具）, 每间隔一定的时间就对云上的服务发起请求。通过请求返回的响应值来判断云服务的状态，从而达到监控的目的。为了接近实时，间隔的时间可以尽可能的短，比如说每分钟发起一次请求。同时为了避免误判，也可以调整设置，当 2 或 N 次以上的请求都显示不可达时，才发出警告提示。这样，当有异常情况出现时，比如确实有服务“挂 ” 了， availability check 就可以第一时间通过邮件通知到相应的团队。或者如果还连接了 SPC 系统 ， 还可以在 SPC 中创建 ticket 通知到一线的云支撑团队。
另一方面，云上的服务只要是 live 状态就可以了么？那么如果遇到服务响应时间下降或者错误率升高，会不会客户很生气，后果很严重呢？这个时候，就需要别的监控工具了。目前正在服役的工具是 Dynatrace 。每个团队可以根据自己的情况定制监控面板。此外在遇到具体问题时，可以跳转到具体的某个服务页面查看相应的指标，比如 Response time, Failure rate, CPU consumption, Throughput ，来分析问题可能的原因，以及相应的对策，比如是否需要增加服务的 instance 或者 memory 。如果调整之后的性能仍然不够满意，那么就需要深入看看代码层面是否有问题，检查是否存在可优化的地方。
除了以上提到的 availability check 以及 Dynatrace ，行业中还有很多其他的监控工具，具体使用哪种取决于公司或者每个团队的选择。
客户在使用系统的过程中，难免会出各种各样的问题，有的疑似 bug ，于是客户一封 ticket 就报了过来。 DevOps 或者开发团队想要重现一下问题， debug 看看。额， debug 对于云产品实在是种奢侈，只好求助于问题发生时留下来的蛛丝马迹。这个时候如果云平台自带的查看日志的命令不够用，比如说 cf logs ，那么就只好借助于 Kibana 这一类的可视化日志分析工具了。
如果说，监控是为了实现更好的服务质量，那么 CI/CD 就是为了在不影响产品质量的前提下更快地交付产品。将 versioning ， build，各种测试，代码扫描，以及 deploy 等步骤作为一个 pipeline 来整体考虑，这是现在更通用的做法。据了解，目前有的团队自己来负责从 Jenkins 服务器到 pipeline的 配置 ， 有的团队则借助于 SAP 内部的 CI/CD 工具，比如目前在服役的 codepipes ，或者piper 。使用工具的优势在于，节省了 Jenkins 或 Bamboo 服务器等维护成本，通过简单的少量配置代码就可以完成p ipeline 的构建。劣势在于，由于这类工具是多个开发团队使用，有资源上受限的可能性，以及当遇到服务器问题时使用上的不灵活性。
所以，在我看来，客户生命周期管理是核心，监控以及 CI/CD 其实也是为了更好的服务于客户生命周期。
DevOps Engineer 的一天，大概是什么样的？
如同前面提到的，不同组的 DevOps Engineer 工作内容可能很不一样。举个例子， 有时候会收到几个 ticket ，急着救火，有时候会耗在配 demo 上，捣鼓半天。有时候在发版的前期跟难用的 pipeline 工具死磕。 DevOps Engineer 不是最懂需求的，甚至也不精于测试和开发。但是会发现当有问题问了一圈无果时，也许问问 DevOps Engineer ，他/她或许是知道答案的那个人，或者能够帮您找到真正有能力解决问题的人。
感谢阅读，以及了解 DevOps 的那些事。
