请首先阅读：
- 一步步实施 DevOps （一）
- 一步步实施 DevOps （二）
Jenkins 不是 DevOps
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。
持续集成可以解决什么问题：
- 能验证代码是否可以正常编译
- 验证组建或模块是否能够集成
- 验证自动化测试用例是否正常运行
- 测试环境的部署
持续集成不能解决什么问题：
- 生产环境的发布
- 部署失败后回撤
- 不能构建环境，虽然支持 Docker
持续集成智能单向操作，代码->构建->测试->部署 等等。持续集成中我们遇到很多问题
例如就是通过 git hook 触发 Jenkins 实现持续集成，自动构建项目。问题来了，任何提交都会触发一次 pipeline 脚本，当项目频繁提交时，第一个构建过程还未运行完毕，第二个进程便启动。导致构建排队，阻塞，同时 pipeline 可能会争夺资源（多个进程读写同一个文件），产生冲突，轻则稍等片刻，重则测试环境崩溃。
另外通过CI 持续集成部署代码也不靠谱，会出现和上面相同问题，例如第一个进程用 scp 复制 jar 包到远程主机，还未传输完成，第二个进程便做同样的操作。
还有 第一个进程重启 tomcat ，tomcat 还未停止退出，第二个请求便发出。最终导致 tomcat 崩溃。
以上的特性，你敢在生产环境上使用吗？一旦发布失败，或者需要回撤，持续集成并没有很好的解决方案。
我认为，持续集成尚不完善，测试环境玩玩可以，生产环境还是不要了。
问题收集
- 产品线都多少条？
- 同时进行并行开发的多少条？
- 怎么进行项目管理？
- 产品团队的情况，怎样管理需求文档，多个产品人员怎样协作
- 开发团队的情况，使用什么语言，什么框架，开发人员数量，采用哪种版本控制，急需解决的问题？
- 测试团队的情况，测试工具，测试的方法，测试用例怎样管理，人员数量，急需解决的问题？
- 运维团队的清况，服务器数量，云的使用情况，docker使用情况，运维工具，运维人员，急需解决的问题？
- 目前最迫切解决的问题是什么？
- 你的企业目前还面临哪些问题（非技术）？
例如来自运维的需求, 运维团队需要什么呢？
- 合同管理
- 成本管理
- 续费管理
- 问题管理
- 突发事件管理
- 环境配置
- 设备管理
- 配置管理
- 自动化部署
- 监控和报警
- 备份和恢复
大部分可以用Issue/Ticket 凑合，我们只捡重点的，环境配置，自动化部署，监控/报警，备份/恢复。
我们就先从监控说起把，你很发现很多 DevOps 的文章中，不会涉及到监控，但是这是运维的重中之重。
每个企业都意识到监控工作的重要性，但80%企业的监控工作仍然处在监控的初级阶段。
什么是初级阶段呢？
- 被动监控，故障发生运维人员永远不是第一个发现故障的人
- 监控IP地址与TCP端口，很多时候HTTP 80端口正常接受请求，但WEB服务器不能正常工作。
- 人肉监控（人肉运维），采用人海战术，桌面摆放很多显示器，甚至投影仪，要求监控者盯着各种仪表板界面，制定各种工作流程以及KPI考核监控人员。
- 人肉测试，要求监控人员每间隔几分钟人工操作一次，以确认系统正常工作，例如（没15分钟登陆一次，下一笔顶单，做一次支付等等）。
- 万能的重启，定其重启所有的服务器。
什么是中级阶段呢？
- 报警：手机短信更靠谱，因为手机随身携带（邮件不算，邮件到达速度慢，各种因素不稳定）
- 监控服务：探测服务的可用性，而不是仅仅监控端口，注意我是指私有协议的监控（HTTP，SMTP,FTP,MySQL 不算在内）
- 故障分析：通过日志与调试工具分析软件BUG，指导开发人员改善软件质量，使其故障不会再次发生，达到不用restart重启方式解决故障
- 半自动化测试
什么是高级阶段呢？
- 我认为高级阶段是监控与灾备系统打通融合一体。
- 除此之外监控与开发密切相关，在开发阶段需要为监控数据采集做铺垫，每开发一个新功能就要想到未来这个功能是否需要监控，怎样监控。
- 数据前期采集与数据挖掘非常重要，监控不仅能做软件与硬件的性能分析，还能提供决策支持，这里又涉及了BI。
- 除了监控，另一个息息相关的是自动故障转移，有兴趣可以看看我的其他文章 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将程序的运行状态提供给监控采集程序。
总结
好的监控的能让你对系统了如指掌，做到心里有数。有数据才好说话。
版权声明
转载请与作者联系，转载时请务必标明文章原始出处和作者信息及本声明。
