一步步实施 DevOps （三）

Netkiller Management 手札

Mr. Neo Chan, 陈景峯(BG7NYT) 中国广东省深圳市望海路半岛城邦三期 518067 +86 13113668890 <netkiller@msn.com>

Copyright © 2010-2018 netkiller

版权声明

转载请与作者联系，转载时请务必标明文章原始出处和作者信息及本声明。

请首先阅读：

1. 一步步实施 DevOps （一）
2. 一步步实施 DevOps （二）

Jenkins 不是 DevOps

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。

持续集成可以解决什么问题：

1. 能验证代码是否可以正常编译
2. 验证组建或模块是否能够集成
3. 验证自动化测试用例是否正常运行
4. 测试环境的部署

持续集成不能解决什么问题：

1. 生产环境的发布
2. 部署失败后回撤
3. 不能构建环境，虽然支持 Docker

持续集成智能单向操作，代码->构建->测试->部署 等等。持续集成中我们遇到很多问题

例如就是通过 git hook 触发 Jenkins 实现持续集成，自动构建项目。问题来了，任何提交都会触发一次 pipeline 脚本，当项目频繁提交时，第一个构建过程还未运行完毕，第二个进程便启动。导致构建排队，阻塞，同时 pipeline 可能会争夺资源（多个进程读写同一个文件），产生冲突，轻则稍等片刻，重则测试环境崩溃。

另外通过CI 持续集成部署代码也不靠谱，会出现和上面相同问题，例如第一个进程用 scp 复制 jar 包到远程主机，还未传输完成，第二个进程便做同样的操作。

还有 第一个进程重启 tomcat ，tomcat 还未停止退出，第二个请求便发出。最终导致 tomcat 崩溃。

以上的特性，你敢在生产环境上使用吗？一旦发布失败，或者需要回撤，持续集成并没有很好的解决方案。

我认为，持续集成尚不完善，测试环境玩玩可以，生产环境还是不要了。

问题收集

1. 产品线都多少条？
2. 同时进行并行开发的多少条？
3. 怎么进行项目管理？
4. 产品团队的情况，怎样管理需求文档，多个产品人员怎样协作
5. 开发团队的情况，使用什么语言，什么框架，开发人员数量，采用哪种版本控制，急需解决的问题？
6. 测试团队的情况，测试工具，测试的方法，测试用例怎样管理，人员数量，急需解决的问题？
7. 运维团队的清况，服务器数量，云的使用情况，docker使用情况，运维工具，运维人员，急需解决的问题？
8. 目前最迫切解决的问题是什么？
9. 你的企业目前还面临哪些问题（非技术）？

例如来自运维的需求, 运维团队需要什么呢？

1. 合同管理
2. 成本管理
3. 续费管理
4. 问题管理
5. 突发事件管理
6. 环境配置
7. 设备管理
8. 配置管理
9. 自动化部署
10. 监控和报警
11. 备份和恢复

大部分可以用Issue/Ticket 凑合，我们只捡重点的，环境配置，自动化部署，监控/报警，备份/恢复。

我们就先从监控说起把，你很发现很多 DevOps 的文章中，不会涉及到监控，但是这是运维的重中之重。

每个企业都意识到监控工作的重要性，但80%企业的监控工作仍然处在监控的初级阶段。

什么是初级阶段呢？

1. 被动监控，故障发生运维人员永远不是第一个发现故障的人
2. 监控IP地址与TCP端口，很多时候HTTP 80端口正常接受请求，但WEB服务器不能正常工作。
3. 人肉监控（人肉运维），采用人海战术，桌面摆放很多显示器，甚至投影仪，要求监控者盯着各种仪表板界面，制定各种工作流程以及KPI考核监控人员。
4. 人肉测试，要求监控人员每间隔几分钟人工操作一次，以确认系统正常工作，例如（没15分钟登陆一次，下一笔顶单，做一次支付等等）。
5. 万能的重启，定其重启所有的服务器。

什么是中级阶段呢？

1. 报警：手机短信更靠谱，因为手机随身携带（邮件不算，邮件到达速度慢，各种因素不稳定）
2. 监控服务：探测服务的可用性，而不是仅仅监控端口，注意我是指私有协议的监控（HTTP，SMTP,FTP,MySQL 不算在内）
3. 故障分析：通过日志与调试工具分析软件BUG，指导开发人员改善软件质量，使其故障不会再次发生，达到不用restart重启方式解决故障
4. 半自动化测试

什么是高级阶段呢？

1. 我认为高级阶段是监控与灾备系统打通融合一体。
2. 除此之外监控与开发密切相关，在开发阶段需要为监控数据采集做铺垫，每开发一个新功能就要想到未来这个功能是否需要监控，怎样监控。
3. 数据前期采集与数据挖掘非常重要，监控不仅能做软件与硬件的性能分析，还能提供决策支持，这里又涉及了BI。
4. 除了监控，另一个息息相关的是自动故障转移，有兴趣可以看看我的其他文章 http://netkiller.github.io/journal/

监控从初级向中继再到高级，是转被动到主动，从人工到自动化。

监控不应该局限在硬件与服务，还应该延伸到业务领域。

你在百度上搜索监控多半是一些开源或商业软件的安装配置指南。这些文章中会告诉你怎样监控CPU、内存、硬盘空间以及网络IP地址与端口号码。

开源软件无非是 Nagios, Cacti, Mrtg, Zibbix ..... 这些软件在我的电子出书《Netkiller Monitoring 手札》中都有详细说明安装与配置方法。

商业软件也有很多如 SolarWinds， Whit's Up，PRTG ......

所有的服务器，网络设备，监控你都做了，那么按照我上面的监控分级，你处于监控的那个阶段？

怎样监控

监控都有哪些手段跟方式呢？

卫星监测

中心卫星站为中心站点向外放射，通常是通过IP地址访问远程主机，实施监控，常用方法是SNMP,SSH,以及各种Agent(代理)，方式是请求然后接收返回结果，通过结果判断主机状态。

Monitor Server
            |
-------------------------------
  |         |           |
[Web]    [Mail]    [Database]

以监控服务器为中心，星型散射连接其他监控节点，没有什么优点，缺点是Web跟Mail节点的通信没有监控

逐级诊断

一级一级的向下探测，寻找故障点，需要在各个节点埋探针。

Monitor Server
              |
-------------------------------      
  |           |             |
  V           V             V
  |           |             |
[Web] ---> [Cache] ---> [Database]
  \                         ^
   `------------------------|

首先监控服务器跟星型拓扑一样监控，再让Web节点去访问Cache节点然后返回监控结果，以此类推，让Cache节点访问Database, 让Web访问Database节点。

将所有业务逻辑都逐一模拟一次，任何一个环节出现问题，立即发出警告。

模拟人工

这里主要监控服务是否可用，可以检查软件的工作情况，涉及测试环节。

通过自动化测试工具辅助监控，例如模拟鼠标点击，键盘输入，可以监控图形界面程序与网页程序。

Windows 监控可以通过 Windows Automation API实现，通过程序控制，能够模拟人工操作软件，实现操作匹配返回结果实现自动化监控

Web页面监控的方案就太多了，比较经典的是Webdriver衍生出的各种工具Selenium - Web Browser Automation最为出名。我通过这个工具模拟用户操作，例如用户注册，登陆，发帖，下单等等，然后匹配返回结果实现自动化监控与报警

数据分析

通过数据分析，将故障消灭在故障发生前。举一个例子，开发人员忘记设置redis 时间，虽然程序一直完好工作，但redis内存不断增长，总一天会出现故障。

我们通过采集redis状态信息，分析一段时间内数据变化发现了这个问题。

监控与开发

谈到监控很多人认为这是运维的事情，实则不然，不懂运维的测试不是好开发。

开发过程中需要考虑到监控，例如Nginx的status模块， MySQL的show status命令, Redis的info命令，都是为监控预留的。那么你开发的程序是否考虑到了监控这块呢？

你可以通过日志形式或者管道，再或者Socket将程序的运行状态提供给监控采集程序。

总结

好的监控的能让你对系统了如指掌，做到心里有数。有数据才好说话。