2018-03-21 15:50
大家下午好，非常荣幸能够有机会在这里和大家分享一下我们中小银行自动化运维的一些经验。
我今天分享的主题是《中小银行构建自主可控的运维自动化体系》
赣州银行是一家位于江西赣州的城市商业银行，在2017年中国城商行排名第56位。规模较小。赣州是革命老区。国家历史文化名城、国家园林城市，生态宜居，大家应该听过赣南脐橙吧。现在算是我们赣州最有名的特产之一。
我是赣州银行系统数据库团队负责人，是一名DBA，做运维做了十多年，之前服务于电力行业，2013年加入了赣州银行，负责系统、数据库架构及运维。2014年完成双活数据中心建设，建立基于虚拟化的双活架构。除核心系统在AS400上运行外，其余的所有外围系统均迁移至虚拟化双活平台。应该说在城商行里率先全面实现服务器虚拟化。
17年负责的课题《自动化工具在中小银行运维中的研究与实践》荣获了银监会银行业信息科技风险管理课题四类成果奖。
传统企业的运维自动化建设呢，最常见的模式就是买，购买这个传统厂商的这些商业产品，国际几大著名厂商我们都有交流过，确实是贵，随便一个都要几百万，而且这种大厂商对我们中小银行快速定制化的开发支持较差。还有一种模式就是自建，这个只有某些技术实力较强的大行才有实力来自主开发来建设，他们有专门的平台开发团队。
而我们中小银行有什么特点：
财力投入有限，没钱， 说银行没钱可能大家都不信，但确实是啊，自从我13年去了银行之后啊，受这个经济下行和互联网金融的冲击，中小银行的日子是越来越难过。而且大部分都要花在业务系统建设上，所以对IT运维这块的投入确实很有限。再一个我们技术人员有限，没人，科技部技术人员不到40人，维护了90多个业务系统，每年还有5、6十个项目建设的任务，我们的运维是没有外包的，都是自己在做。人员很紧张。而且我们位于三线城市，很难招到合适的人员，厂商支持的力度也很有限。远水救不了近火，这就要求我们运维要做到自主可控，不能去依赖厂商。
因此，购买和自建我觉得都不适合我们这样的中小银行。所以我们主要是依靠一些优秀的开源软件产品，在这基础上进行一些开发，这样来实现自主可控。
我们的运维自动化建设主要可以分为这么3个阶段：
一是自动化监控，在这个阶段实现对应用系统的一个全方位的自动监控。
二是操作运维自动化，在这个阶段呢，把手工执行繁琐的操作通过工具编排成作业自动执行。
这2个阶段呢是个运维自动化基础保障的阶段，第3个阶段呢是运维开发的阶段，通过运维开发更多的自动化工具，比如故障自愈，实现故障的自动处理，来真正实现运维自动化。下面我将从这3个方面来介绍以下我们的运维自动化建设。
首先，自动化监控，开源的监控平台有很多，zabbix、nagios、openflacon等等，应该说都很优秀，各有各的特点，我觉得重点是根据企业的实际情况去建设一套适合自己的监控平台。
结合我们自身的实际情况，我们在做监控平台的时候主要是关注以下几个方面：
第一个是能够快速实现自定义监控
在应用运维中会有非常多的个性化的监控需求，CPU、内存这些基础的监控是远远不够的。而且这些监控需求随着业务的发展是不断的增加的，这就要求我们的监控平台能够快速的去实现这些个性化的监控需求。而且即便最基础的监控有时候也需要去做一些个性化的调整，举个例子啊，磁盘空间监控，大家一般去监控什么？磁盘空间使用率，对吧，100G的空间，使用了80%就进行告警。但是我们就有个业务系统碰到过一次故障：
磁盘空间使用率72%，但是应用已经无法写入了，导致交易失败，为什么呢，就是因为Linux文件系统的索引节点空间使用完了！文件系统是分为数据区和索引节点区的，数据区存放的是文件数据，索引节点存放了文件的元信息，比如文件的字节数、拥有者的userid、读写权限、文件数据block的位置，每一个文件都必须有一个索引节点，由于这个应用的机制是每笔交易产生一个日志文件，就导致应用产生了大量的交易日志，每一个日志的大小又很小，所以就出现了数据空间使用率才72%，但是索引节点空间使用率已经到100%了，交易就全部失败了，由于我们的监控只监控了数据空间，那就没能及时的发现这个问题。那由于我们的监控平台是开源平台，监控程序都是自己写，所以我们马上就修改了这个监控的程序，对这个磁盘空间的监控同时监控数据空间和索引节点空间，任一空间达到告警阈值都马上告警！避免再次发生此类故障，大家回去也可以检查下，自己的监控是不是只监控了数据空间？
因此我们认为能够快速实现自定义监控是监控平台最为重要的一点。
第2要对监控数据的分析，大家知道监控平台会产生大量的监控数据，这是我们运维中的重要数据，因此一定要利用好这些数据，对这些数据进行分析，去了解应用系统的整体的运行趋势，这样才能及早的发现应用系统的一些隐患，从而避免故障的发送。又比如我们有个应用系统，正常情况下每个月数据增长量也就1个G，突然有个月增长了30G，但是空间还是够用的，没有达到阈值，因此监控平台也是没有告警的，但是我们通过数据分析就发现了这个问题，跟以往比数据增长量突然增加了30倍，肯定是有问题的，于是就让开发去查，果然新上线的一个程序存在bug，数据重复写了30次。因此，做监控一定要好好利用好监控产生的这些监控数据。通过这些数据去掌握系统的整体的运行趋势。提前去发现一些隐患。从而避免故障的发送。
第三，我们觉得监控要能够灵活的配置这个告警。因为各种各样的监控，告警的需求也是不一样的，有的需要在故障期间一直发短信或发微信，有的只需要发一次，有的需要一检查到异常就发，有的则在多少分钟后仍然异常再发，等等，各种需求。这就需要监控平台都能灵活配置支持各式各样的告警。
第四一个是界面简洁易懂
因为我们的机房运行值班人员不是专业的技术人员，所以一个中文 s简洁的界面方便机房值班人员查看整个数据中心的运行状态。
以上4个方面就是我们做监控关注的4个点，目前我们是使用的icinga开源监控平台，开发了大量的个性化监控程序来实现了应用系统的全方位自动化监控。
第二部分是 运维操作自动化：
我的团队主要负责系统和数据库的运维，在系统数据库这些基础架构的运维方面，通过脚本和ansible很早就实现了自动化运维，数据库一键安装、一键批量巡检、一键系统补丁安装、数据库的自动扩容等等。但应用运维之前主要还是登录到服务器上纯手工操作，由于单个应用系统的服务器数量不是很多，最多的一个系统也就二十台左右，因此不出问题的情况下应用运维觉得还是勉强能够满足日常的运维需求。
但是这种人工操作效率低下，还容易误操作。还比较依赖于这个应用维护人员，换个人还不太会操作，这就导致了应用在出现了故障的时候故障恢复时间比较长，经常要等这个应用的负责人来操作，这种手工操作起来效率又很低。
在或某些重大变更或者灾备演练（银行每年都要求做灾备演练）的时候，大量的应用系统都需要做操作，银行的安全等级较高，所有的生产操作都必须要ECC监控中心去通过堡垒机来操作，我们的ECC又不是很大，每次ECC监控中心都被挤满了人，系统、数据库、网络、应用都要操作，操作机就十几台，所以应用运维经常要排队来等操作机，效率低下且容易出错，由于应用运维的这个低效率导致所有人员都要耗在那里等。因此我就觉得这样不行，太浪费时间了，于是我就开始推动应用运维自动化。
首先是做了脚本化、标准化的工作，要求所有应用运维统一了基础的操作命令：
比如所有应用系统的启动、停止。统一定义到linux的service:
service app start/stop/restart/status
所有的应用都用统一的命令来操作，这样应用在有故障情况下不再依赖于某一个人，随便一个运维都可以操作了。
第二，批量调度 因为系统数据库运维我们一直是用Ansible，所以一开始也想用ansible来做应用运维。但是，发现不太合适，权限不好控制，应用运维也不容易上手。
还是觉得应该做一个图形化的自动化运维平台，严格控制权限，同时要方便编排作业，能够让应用运维能够不需要直接登录服务器通过这个平台就能够完成日常的运维操作，并能够记录每次的操作日志。
一开始我也是想试着自己用python开发，但是干了几个月没多大进展，对于我这个没正经干过开发的人完全从头搞这么一个平台确实太困难了。
正好在这个时候，正好来北京出差，顺便听到了腾讯蓝鲸党总的演讲，我还记得党总的PPT封面是“遇见蓝鲸，也许是个机会”，今天我想说，遇见蓝鲸，确实是个机会！
蓝鲸作业平台按应用系统来控制权限，操作简单方便，支持多种语言，能够快速定制作业，还能够分发文件、定时作业。而且还记录了每次执行的详情，做到了可追溯的操作审计。
这不正是我想要的自动化运维平台吗？
党总在那次还分享了腾讯游戏如何从0打造百人级别的Devops团队。那次分享让我受益匪浅，我回去后呢就拿党总的PPT给领导和同事们讲了一遍，讲腾讯游戏如何做运维，运维如何做运营，我说我们要像这些互联网企业学习！领导也很赞同，所以我们在经过测试后很快就把蓝鲸配置平台、作业平台上了生产。因为能够帮助应用运维提高效率,因此很快就把作业平台推广开了。
大量的日常运维操作都通过作业平台快速完成：重启、发布、日志归档清理等等。
同时把大量系统中的运维定时任务(crontab)也迁移到蓝鲸作业平台
以往运维中的定时任务通过操作系统的crontab ，有这么几个缺点：
1、太多定时任务，不方便管理，维护困难，在做一些重大变更的时候需要手工把定时任务注释掉，变更后要手工跑一遍再恢复定时任务，工作量巨大且容易遗漏。
2、不方便统一监控，出现过定时任务未成功执行而没有及时发现的情况。比如系统用户密码过期的话会影响定时任务的执行。
因此，我们通过蓝鲸作业平台来统一管理定时任务，效率更高，也方便查看执行的详情。
那么蓝鲸上跑了这么多定时任务后，蓝鲸也就显得很重要了，那就一定要加入监控。我们利用监控平台监控了蓝鲸的基础进程的状态，还监控了蓝鲸作业平台定时作业执行的情况，这边分享下如何去监控蓝鲸作业平台中定时作业的执行情况，是通过job查询数据库来监控的，通过查询数据库中定时任务执行情况能够很方便的知道一天有多少定时任务，执行成功的有多少，失败的有多少。如有执行失败的定时任务则马上通过自动监控平台进行告警！
这就是我们作业平台的一个应用情况，在作业平台推广后，我们想要实现故障自动处理，那时蓝鲸的故障自愈app还没推出。于是就学习了蓝鲸的ESB文档，通过蓝鲸的ESB，开发了一个故障自愈小程序，实现监控平台和作业平台的联动，当自动监控平台监控到应用故障时，
故障自愈程序自动去判断这是应用的故障，而不是网络的故障或监控自身的故障。在确认故障后自动的调用预先配置好的故障处理作业，自动的处理，快速的恢复。
这是故障自愈的一段日志：可以看到，凌晨4点32分的时候监控到一台柜面的应用故障，然后自动的调用了重启应用的作业，自动就恢复了。以往如果是这个时间去通知相关人员来人工处理的话，至少也得1小时。通过故障自愈程序1分钟就完成了故障的处理，完全不需要人工干预。故障自愈不仅能实现最常用的应用自动重启，能够实现什么完全在于应用运维自己区定义，比如通过故障自愈帮某应用实现了加密机的高可用：
有一套加密机没有做到负载均衡，应用也没有做到自动切换，完全是个冷备，有段时间加密机老出问题，自动宕机，每次都要应用运维来手工做个切换，导致故障最快都要半小时才能恢复，严重影响业务。后面我们就把这个切换的一个步骤定义到作业平台，并配置故障自愈，当监控平台监控到某一台加密机故障时，自动的调用作业平台中定义的加密机主备机切换作业，快速的完成切换，现在通过故障自愈调用蓝鲸作业平台，不到1分钟就完成了，极大的减少了对业务的影响。
当然，也可以基于蓝鲸的开发框架自己快速开发一个saas应用。我们目前就基于蓝鲸Django开发框架，利用vmware官方推出的python sdk，开发了一个saas应用：云管理平台，实现了我们基础设施的运维自动化。前面有提到，我们在2014年服务器就已经全面的虚拟化了，在生产和开发上使用了大量的虚拟机，那么在日常运维当中的大量的虚拟机安装部署，以往我们的安装流程是这样：
应用系统提出申请，申请通过后虚拟机管理员通过手工克隆模板，
克隆完成后去修改相关的硬件信息，再打开电源到主机里面配置网络等信息，然后再发OA把相关信息告诉开发人员，效率低下。整个流程走完大概要20分钟。
现在我们通过云管平台申请，在云平台里直接审批，审批完成后就能够一键安装，安装完后呢自动的交付给开发。实现了基础资源的快速交付。
另一个重要的功能呢是实现了虚拟机的自动合理分布
先要介绍下我行的双活虚拟化架构：
我们的2个数据中心，相隔5公里，通过DWDM构建了同城双活数据中心的光传输网络，为跨中心数据传输提供了高带宽、低时延、高可靠的通道。存储层通过Vplex实现了存储双活，两个中心各有10余台X86服务器共同组成了一个vmware集群，集群里跑了我们的数据库、应用的虚拟机，这些虚拟机可以在线的在2个数据中心切换。但如何让同一个应用系统的虚拟机合理的分布一直是我们的一个难题，举个例子:
假如某应用系统有4台应用服务器，那么它的合理分布应该是2台在主中心，2台在同城，而且4台分别运行在不同的物理主机上，这样当某一台物理主机宕机时，就只影响其中一台应用服务器，只有这一台会自动重启，把对业务的影响降到最低。以前我们都是通过人工来管理，根本没办法保证虚拟机是合理分布的。现在我们通过开发的这个云管理平台就根据各物理主机资源的使用情况来合理分布各应用系统的虚拟机，确保各应用系统的虚拟机不跑在同一物理主机上，并实现了三种模式的一键切换：
主中心模式：一键合理的把所有虚拟机分布在主中心的物理服务器上。
同城模式：一键合理的把所有虚拟机分布在同城中心的物理服务器上。
双活模式：一键合理的把所有虚拟机分布在2个数据中心。
通过云管理平台实现了vmware平台虚拟机的合理分布和自动化管理。
这就是我们基于蓝鲸统一开发平台开发的saas应用。
从接触蓝鲸到完成云管理平台的开发上线，我们没花钱，3个人用了10个月的时间，
要感谢蓝鲸帮助我们快速、低成本的建设了我们的运维自动化体系，
目前正在基于做更多的运维开发。开发更多的saas应用，提高我们的运维效率，降低运维风险。
这是我今天分享的所有内容。谢谢大家。