dev+ops?
对于devops的理解,似乎很长一段时间都在混沌状态。这很像早期网格计算,云计算初期每个人解读的版本各有不同。同一本圣经,最后还不是由于不同信徒的解读导致产生了天主教,东正教,新教的各种分支吗? 所以解读很重要。
传统上,大家认为devops就是让dev干ops的活,干掉ops这个岗位,给老板省钱。小企业用云厂商方式搭建的应用上(其实还是要有懂ops的人)似乎可以这么搞,持有大规模私有云的企业适合这么干吗?
这两个词合在一起其实可以从两个方向看:
dev >> ops
很明显,这是要dev有运维能力,加运维技能点。dev << ops
反过来,运维为了减少人肉,要有开发能力,开发自己需要的系统,进行自动化运维。
两个方向合力,各自都在自己的地盘上多跨一脚,成就了别人,也造就了自己。我们想要的就是在工程效率上的提升。
Google的devops
这件事上Google继续领跑,去年Google出了一本书《Site Reliability Engineering》给出了答案,SRE就是Google版本devops的最佳实践。
其指导思想就是开辟了SRE岗位,让此岗位的人具备研发能力,自研支撑系统来代替传统上各种需要人工操作的地方,保证系统规模不断扩大时系统工程师别跟着线性增长。SRE招聘上有两类:一类与正常的软件工程师技能要求一样;另一类工程师技能可能稍弱但有其他技能(UNIX内核,三层网络)加成。
devops作为一种开发模式的转变,我认为其提供的其中一种积极的作用在于,让传统上分裂的开发和运维部门更多的协作,而不是对立。
例如开发关注点在于功能的交付,运维关注点在于系统稳定和安全。通常一个渣渣系统出问题,可能半夜先被叫醒的是Ops而不是Dev,当Dev不深受其苦时其系统稳定性是没有内在动力的。
运维友好的应用
当开发更多的参与运维的工作后,切身的体会到需要改进的痛点后,变化就来了。比如, 开发出运维友好的应用。
什么是运维友好的应用?
James Hamilton 在Windows Live Services Platform 2007这篇论文里提到:
While auto-administration is important, the most important factor is actually the service itself. Is the service efficient to auto- mate? Is it what we refer to more generally as operations-friendly? Services that are operations- friendly require little human intervention, and both detect and recover from all but the most obscure failures without administrative intervention.
运维友好的应用几乎不需要人工干预,极个别难解的故障外都可以被自动检测并恢复。
此文章主要介绍了Windows Live Search团队在交付运维友好的服务时总结的最佳实践,如今仍然有指导意义。此处不做展开,文末引申阅读里列出了下载地址,可自行观看。
Design for failure
开源界典型的业界范例可以参考Netflix贡献的eurka,DropWizard等产品的设计思路,此类基础程序在设计之初就考虑到了分布式系统的容错,系统监控自包含并提供http接口和简单图形界面。
以Eureka为例,作为设计在云计算环境使用的服务发现组件,认为服务失效是个常态,所以在服务失效时客户端代码有本地缓存,会自动将请求分发到一台新的服务地址上,实现故障转移。 而Eureka的服务端,会对发布在其上的服务器进行健康监测,在心跳缓慢或丢失时自动将服务器剔除,达到自动容灾的目的。
此处可引出很多内容(自我保护,容灾,限流,降级,监控,分组隔离,进程隔离,线程隔离,容量规划,基线管理,超时控制,重试控制,无状态化),真要聊,还是另开场地吧~
方便的监控
现代服务都有良好的后台,方便的看到系统内部状态,eureka 界面如下:
eureka也被集成到了spring cloud中作为服务发现的组件,其界面也是大同小异的:
由上也可看出,什么叫运维友好?自己的服务,能在一处统一的地方看到内部的运行状态,这在观测系统行为和排查问题时是极为有用的。
依赖控制
java依赖通过maven控制,为啥系统依赖要割裂出来用各种基线来控制呢?还是用docker image解决系统级的依赖吧,不过似乎大多数java应用除了jdk,tomcat其实也不需要太多此种依赖,除了外挂的各种采集类的agent。
自动化
最近Gitlab.com发生的删库后,陈皓的一篇文章阐述了一个观点
一个公司的运维能力的强弱和你上线上环境敲命令是有关的,你越是喜欢上线敲命令你的运维能力就越弱,越是通过自动化来处理问题,你的运维能力就越强。
这是必要的,按照规范将大量繁杂活自动化,命令都固化到脚本或程序中去,让程序准确无误地执行。
好了,就这么多了,欢迎拍砖
—
延伸阅读:
On Designing and Deploying Internet-Scale Services
Netflix源码解析之Eureka:Eureka client 注册过程
本文来自微信公众号「麦芽面包,id「darkjune_think」
转载请注明。
微信扫一扫关注公众号。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。