<netkiller@msn.com>
Copyright © 2010-2018 netkiller
版权声明
转载请与作者联系,转载时请务必标明文章原始出处和作者信息及本声明。
请首先阅读:
Jenkins 不是 DevOps
持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。
持续集成可以解决什么问题:
持续集成不能解决什么问题:
持续集成智能单向操作,代码->构建->测试->部署 等等。持续集成中我们遇到很多问题
例如就是通过 git hook 触发 Jenkins 实现持续集成,自动构建项目。问题来了,任何提交都会触发一次 pipeline 脚本,当项目频繁提交时,第一个构建过程还未运行完毕,第二个进程便启动。导致构建排队,阻塞,同时 pipeline 可能会争夺资源(多个进程读写同一个文件),产生冲突,轻则稍等片刻,重则测试环境崩溃。
另外通过CI 持续集成部署代码也不靠谱,会出现和上面相同问题,例如第一个进程用 scp 复制 jar 包到远程主机,还未传输完成,第二个进程便做同样的操作。
还有 第一个进程重启 tomcat ,tomcat 还未停止退出,第二个请求便发出。最终导致 tomcat 崩溃。
以上的特性,你敢在生产环境上使用吗?一旦发布失败,或者需要回撤,持续集成并没有很好的解决方案。
我认为,持续集成尚不完善,测试环境玩玩可以,生产环境还是不要了。
问题收集
例如来自运维的需求, 运维团队需要什么呢?
大部分可以用Issue/Ticket 凑合,我们只捡重点的,环境配置,自动化部署,监控/报警,备份/恢复。
我们就先从监控说起把,你很发现很多 DevOps 的文章中,不会涉及到监控,但是这是运维的重中之重。
每个企业都意识到监控工作的重要性,但80%企业的监控工作仍然处在监控的初级阶段。
什么是初级阶段呢?
什么是中级阶段呢?
什么是高级阶段呢?
监控从初级向中继再到高级,是转被动到主动,从人工到自动化。
监控不应该局限在硬件与服务,还应该延伸到业务领域。
你在百度上搜索监控多半是一些开源或商业软件的安装配置指南。这些文章中会告诉你怎样监控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将程序的运行状态提供给监控采集程序。
好的监控的能让你对系统了如指掌,做到心里有数。有数据才好说话。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。