又拍云运维总监邵海杨详解 DevOps “八荣八耻”(3)

△ 以自动化工具为荣,以手动和人肉为耻

公司早期,用的是bash、sed、awk,因为我之前有搞嵌入式的背景和经验,对一个十几兆的嵌入式系统来说,上面是不可能有python/perl/nodejs等环境.

所以我们把服务器批量安装,部署,做成了嵌入式的系统后,只要点亮以后,运行一个硬件检测的程序,会把机器的CPU、内存、硬盘大小等都打印出来,供货商截图给我看,这个机器是否合格.

合格的机器可以直接发到机房去,在机器到了机房通上网线以后会有一个ansibleplaybook的推动.

自从用了这种方法以后,我们在公司里面基本上没有见到服务器,一般直接产线上检测通过后发到机房.

然后我们运维人员就可以连上去远程管理,在过去的三年里我们服务器平均每年翻了三倍,节点翻了六倍多,但是人手并没有增加.

关于tgz、rpm、pkg的打包部署,我们用的是tgz的打包及docker镜像.优势在于,我们自有CDN网络,软件通过推动到CDN网络下可以加速下发.

关于集成测试、自动测试的发布,像ELK集中日志的分析、大数据的分析,我们现在使用ELK以后,只要有基础的运维技术知识便可看懂,不需要高深的运维知识和脚本编辑知识,大多数人都可以完成这份工作,好处就是你多了好多眼睛帮你一起来发现问题,定位问题.

最后是不要图形,不要交互,不要终端.一旦有了图形以后,很难实现自动化.原则就是,不要手工hack,最好是用程序生成程序的方式去完成这个步骤.

八、以无人值守为荣,以人工介入为耻

△ 以无人值守为荣,以人工介入为耻

运维部门要做的事情有三件：

1. 运维自动化

要有一定的业务抽象能力,要有标准化的流程.没有好的自动化,就很难把运维的工作效率提升了,只要做好这些,就可以节省时间,从容应对业务增长.

而且运维自动化的另一个好处就是运维不会因为人的喜怒哀乐而受到影响稳定性,比如说我今天心情不好,你让我装一台机器我还可以忍,你让我装十台一百台就不行了.但如果公司有了运维自动化的流程,这个事情就可以避免,因为谁做都一样.

2. 监控要常态

2016年年初,我们特别成立大数据分析部门,我们把日志做了采样收集和过滤,通过大数据平台做日志的同构数据分析,重点关注4xx/5xx/2xx比例,响应时间分析如100毫秒、200毫秒、500毫秒,还有区域性的速率分布,讲真,这真是一个好东西.

3. 性能可视化

数据的有效展示.现在ELK对我们的帮助很大,从监控图上来看相关的数据指标,一目了然.这里就不反复赘述了.

DevOps的本质

最后,我们谈一谈DevOps的本质.

1. 弹性

像亚马逊推云时,那个单词叫elastic,意思是,你要能够扩展,如横向扩展；你要能负载均衡,如果你是基于openstack/docker资源池,你的资源就可以复用,可以编排回滚.

比如说OpenStack有模板,我打一个镜像包,稍微重了一点,Docker的就轻一点,Docker可以做一个滚动发布,可以保留原来的程序、原来的容器,你可以做快速切换,这也是一种变化的弹性.

2. 无关性

如果是虚拟化资源,一切都可以在模板里面设置,可以把底层的硬件、系统、网络抚平差异,比如说不管物理磁盘是1T(市面上缺货)/4T/6T的盘,都可以划分100G容量,所以当把一切变成按需申请的服务,无论是开发还是运维,工作都会比较简单,因为它的无关性.

3. 不可变的基础设施

这个对传统运维可能是一种打击,因为基础镜像可能已经做的足够安全,足够完美,足够精干,不需要基础运维过多的人工参与.

但我认为恰恰能帮助传统运维减轻工作量,反而有更多的精力去迎接虚拟化、容器化,SDN的挑战,掌握了新技能后,就可以随取随用.

我现在是用比较开放的心态去接受这些变革,比如说像CoreOS这个操作系统,你到里面去看一下,真的没什么各种组件,除了最基础的就只有docker/RKT运行环境.

当然,这个是很极端的例子,但是我觉得当底层的操作系统,他可以做到自我更新,足够安全的时候,确实不需要你去操心这个事情.这跟我们用小U盘做整体升级的思路是一样的,但是它那个更先进,更彻底,更值得我们去学习.

Heroku PaaS的12要素宣言

Heroku是业内知名的云应用平台,从对外提供服务以来,他们已经有上百万应用的托管和运营经验.前不久,创始人AdamWiggins根据这些经验,发布了一个“十二要素应用宣言(TheTwelve-Factor App)”

1. 基准代码

一份基准代码多处部署,这个就是刚才讲的标准化,还有复用组件,这些是吻合的.

2. 显式声明依赖关系

比如说像nodejs、go、maven,在提供的配置文件上,要标明上下游的关系,标明可配参数.

3. 必须要在环境中存储配置

这一点我觉得可以保留,虽然文本文件也适用,但环境变量有它的好处,一是语言无侵害性,二是代码无关性.比如说OpenStack里也有环境变量,它是会导入环境变量的那份文件.

4. 要把后端服务当做一个附加资源

这就是我们一直在强调的松耦合,要把后端服务变成一个url去调用,像Mysql,或者是通过消息队列或任务框架.或者更加智能一点,做自动的服务发现、服务注册,把后端服务剥离开去.

这样做的还有一个好处,就是能够区分运维工作中哪些是重点资源,哪些是需要更多的人去监控后端的服务,当知道这是重中之重的时候,就可以把有限的运维力量投到上面去.

5. 构建、发布和运行

用了Docker以后就很容易实现这个标准,关键是统一性、标准化和模板或容器格式.

6. 进程必须是无状态而且无共享

任何需要持久化的数据都要存储在后端服务里.

7. 要做端口绑定

要通过端口绑定来服务,你可以基于Restful,也可以基于rpc或者是http,这样的好处是松耦合和方便负载均衡,做水平扩展.

8. 并发

要通过进程模型进行扩展,方便扩展.

9. 易处理

快速启动和优雅终止可最大化健壮性.参考雅虎原则.

对雅虎来说,如果开发需要上线服务,就必须向运维提供start、stop、status、reload/restart这几个开关,如果你不提供这些开关的话,雅虎的运维是不允许这个服务上线的.

因为能提供stop,那就说明服务是能被随时重启的最好证明.

10. 开发环境与线上环境等价

尽可能保持开发、预发布和线上环境相同.用了Docker以后,这个事情就不是个事情.

11. 把日志当做一个事件流

我们现在用logstash和heka去做一些处理.对云服务来说,我们现在发现,日志越来越重要,日志收集对我们来说价值非常大.

通过大数据分析平台,可以做到秒级分析,秒级监控报警,秒级定位问题,甚至我们可以比客户更早发现问题,我觉得这是一件非常有意义,值得我们投入精力去做的事情.

12. 管理进程

后台管理任务可以当做一次性的进程运行,相当于微服务.

（编辑：ASP站长网）