大家好!很高兴今天来到这儿跟大家分享我们对于自动化的探索和实践，首先先做自我介绍，我叫季文轩，本人是做云出身的，从2013年开始做公有云的交付，大大小小交付的云平台应该有十几家了，有中国第一个广电行业的云是我们交付的，中国第一个铁路的云是我们做的，在之前也给数据中心做过云化的数据中心，有将近近万台的虚拟机的交付规模，所以说我本身是有情怀的程序员，一直也是在做自动化的建设，还有相关的工作。所以我既是产品负责人，我也是这个产品的典型用户。
首先来说我们做自动化运维的初衷，因为我一直在做云平台的交付，少说我最近在交付的，上个月我们过完年交付的平台大概有800台的物理服务器，在这上面预计大概有8万台虚拟机，随着互联网的发展，云计算也好，大数据也好，大规模的计算机群越来越多，所以在这个情况下，我们应该把握这些通用的特定场景去做到极致的自动化，现在这个场景成熟了，已经可以做深度的自动化了。
相对于传统云平台来说，因为我早期是做公有云交付，在那个阶段，大概在2012年、2013年的时候还用传统的手段这种技术工具来做自动化，我们都会面临几个问题。首先是一个公云平台，每天虚拟机在收缩、增长，我们机房运维人员很难做高效维护，缺乏高效的运维机制，缺乏高效的运维工具，相对来说都比较被动，一般情况下客户给我们提了工单或者打电话我们再去处理这个问题，所以我们经常会违反一个SLA。
自动化运维的实施模型，因为很有幸在去年的时候，因为公司需要，我专门去研究了一段时间，发现真正一个好的闭环流程才是最重要的，所以在我的自动化运维体系里面，做到了ISO20000“四话”原则，管理体系化、工作流程化、任务自动化和专业人员化。可以说一下我们大致几个功能，这个平台是我们去年6月份的时候开源，一直到现在，因为我本身是做技术出身的，对开源，因为我本身或者我们公司也都是开源的受益者，所以我们选择这种方式来回馈开源，会有几个功能给大家介绍一下。批量的安装系统，安装操作系统对我们来说比较困难，比如铁路这个云，在早期安装系统和安装平台分开两步去进行安装，当你安装操作系统不统一，去触发物理环境不统一，我跑在上面就会面临风险，所以我们为了标准化，在这里初始化操作系统，初始化云平台和应用，做到任务编排和大数据分析、资产的管理。
首先说任务编排，因为我们在早期做的时候先做任务，因为运维通常很多巡检、部署运维的工作，所以我们早期做任务编排，去做周期性的任务巡检，周期性帮你执行任务，周期性帮你执行一个脚本，后来我们发现这种场景太过单一，所以我们现在在开发的这一版可以做到任务的编排，当你去制定一个任务，这个任务成功之后那我去执行什么?这个任务执行失败之后我去执行什么?可以去自定义工作流，他帮你做场景判断和场景检查，相对来说降低运维人员的时间成本。
自动装机和操作平台，我们平台本来是开源的，我们新版本预计是今年7月份会放到平台上来，我们大概一年一个版本。我们没有做太多改造，只是说装操作系统的时候重新编一下程序，帮我去格式化Redhat，去帮我配置IPMI，我们做虚拟化很多时候需要做Redhat，尽量降低初始化的能力。
做监控，我们自己做了一个监控，监控是我做的几个模块里面工作量大，也是最用心的一个，因为后期整个平台由监控来驱动整个平台，比如说我来举一个比较极端的场景，因为平云台支持负载均衡，当物理机宕机了，我的虚拟机被重新从计算机运作起来，当我发现这台机器不通的时候，我可以调我的平台进行重启，在极端场景下我可以做到把这台机器自动重装系统，再将它上线，这是一个很极端的场景，最开展我们做的任务由人驱动，后来由监控驱动，比如你磁盘空间快满了，你可以通过监控驱动任务，由任务去帮你进行数据规则。
我们针对OpenStack，因为我专门有一个团队去做监控，这个团队写了大概1000个指标项目，完全覆盖了OpenStack硬件和系统层面上的监控项目，也不再像通常的监控一样需要配置模板，需要你去报触发器，会自动根本你当前的节点，装了多少硬件、装了多少软件自动采集、自动上报、自动取出图，而你要做的是在首页创建自己的仪表，创建你自己关心的项目。
下面是大数据分析，这个可能和蓝鲸的做法不太一样，因为我真的是有一拨数据挖掘的团队，针对于OpenStack所有的日志进行了数据挖掘和数据建模，因为我们觉得真正到了云的级别，单纯去考虑每一台机器或者这一个物理服务器，已经没有太大意义了，我们针对云来做数据分析，我可以给客户提供业务数据，我可能告诉你这个月的增长量是什么，你的虚拟机在什么时间点会消灭，什么时间点会衰减，什么时间点会弹，因为整个平台我们是依附于云来做，云是支持负载均衡，而且这种业务场景、业务上的数据客户也需要，而我的下一步除了由监控去驱动我的任务，我下一步由我的数据来驱动我的业务，由业务再去驱动我的任务或者驱动我的平台来做更智能的事情，我们下一节点也是再做智能的运维。所以大数据分析是我们现在已经做完的。
而且整个平台日志分析和我的监控也都是采用一个模式，因为我本身做运维出身，自动化本身是懒人的想法。
应用的部署，通常来说软件相对比较简单，部署一套完整的OpenStack在几十台、几百台的规模相对来说都是比较痛苦的，如果在座的里面有去部署OpenStack的手工部署，大家一定觉得部署OpenStack太痛苦了，我从2012年玩到现在，我没有这个自信全部装起来，大部分熟的我可以搞定。所以我们把整个OpenStack做成应用模板放到应用里面，可以通过平台自动去部署OpenStack不需要看一定能成功，在这个过程中它没有出错的道理，一定是会成功的。尽量做到模块化，有微信的遥控，我们可以做到微信的遥控，可以通过微信语音去进行查询，查询有多少机器，出问题的机器是哪些，这些机器出了什么问题，都可以用微信去查，包括结合大数据，我今天业务的增长量多少，我今天的业务衰减又是如何，而且可以通过微信去进行遥控，包括哪台机器重启，包括哪台机器做数据应用都是OK的，下一步我会根据微信，因为相对于微信和邮件来说，微信的时效性更好。
下一个点是做智能化告警，由数据来驱动我的微信，通知相应的人，其实我们现在已经做了一部分的日志分析，已经做了一部分智能化处理，比如我的硬盘，现在可以通过我的监控告诉我的客户这台机器这块硬盘在未来的什么时间点会坏，如果说你不进行更换和处理，那你要承担这个风险，比如你的网络负载，比如你的整个，因为到这种云的近千台机的级别不是某台机器或者某个云，如果不进行处理这个机器会发生什么样的问题，我们现在可以根据大数据平台通过微信去实时推送，可以根据增长的趋势告诉你，如果说你现在不处理这个问题，它在未来时间点是有隐患的。
是一个联动，这个图是我们在早期的，因为时间关系没有来得及去改，我有一个Master，可以做到自动上线，自动部署我的应用，以完成完全的自动化。这是我的一个架构，上层，因为我们现在也是做了相关的分离，前端业务人员给IT人员提供接口，其实在我上层页面也是可以进行自己编排的，做了功能编排，我会针对不同的场景、不同的客户、不同的需求去做不同的门户，因为我API是统一的，从API去编排不同的业务功能，这一块和蓝鲸也比较相似。
再往下，我也做了资产，做了批量部署，日志的审计，监控，还有微信告警，其实在我下一个时间点，资产会是我弱化的一个功能，因为我发现对于运维的视角，因为我本身就是做运维出身，因为在运维的视角里面关心的真不是资产，而资产的详情更多偏财务关心，所以运维关心的是这台机器上有多少硬盘，更多是围绕服务器，而且围绕这个图，我的产品在资产这一块会做机柜图，因为我当发现我的这台机器快出问题的时候我打电话告诉一线人员哪台机器快出问题你去看一下，这个人的第一反应是你的计算机在哪，哪台机器，我们做了完整的机柜图，我可以打开这个机柜的图看看这个机柜是不是正常，我可以打电话跟我的兄弟说，你去帮我看一下从下面数第几个机柜出了问题，你去帮我看一下，我觉得更多的资产是做到这个视角。监控和大数据是我们自己实现的，这套平台我们现在这个版本，在微信的版本，我们会在7月份的时候开源，其实去年已经开源一个版本，大家有兴趣可以来找我，我们一起去玩。
这是我的客户分享，我的云化数据中心的客户，这个客户是北京、上海、香港三个数据中心，它是一个云化数据中心，在整个平台里18000多个监控项目，4000多个触发器，280多台服务器，18000多个监控项目有一部分为了业务输出去，所以那些不关心，不告警，更多出主机图。而这三个地区所有的运维人员加起来5个人。
其实这个没什么好说的，通过监控来降低了人工，统一平台降低了学习平台，通过标准化降低了出错率，因为整个平台从我的系统安装到应用上线到后期的维护到监控到管理，都在我的平台上完成，我的平台就会对这个运维人员所有的操作进行安全审计。这是现在开源的一个版本的界面，大家可以看一下，任务的调度、任务的编排、告警、应用。
最后是对运维的展望，或者说我们下一个点要做的事情，结合大数据要去做人工智能。我觉得现在的互联网发展，计算机学这么普及、这么大，因为我现在看计算机集群少一点的都几百台，所以说我觉得可以通过集群化的特点去做到很极端的自动化，我觉得这是没问题的。统一平台全站管理，因为相对来说可能早一年、早两年的运维工具相对分散，有做网络的有专门做网络的平台，有资产的有专门做资产的平台，做监控的有专门做监控的平台，我现在做到统一平台，他们之间首先来说节省了统一去维护一个主机列表，做到全站管理，降低了人员的学习成本。
最后是以Itii为核心，可以节省很多时间成本和流程。
最后是我们公司的介绍，我们公司是第一个在IDC行业基于开放技术建设的公有云平台，我们是广电行业第一个基于开放数据建设的广电云平台，大概800台机器，几万台虚拟机的规模，拥有40家云生态的合作伙伴。
我的分享就到这里，如果大家对产品感兴趣可以联系我，谢谢!
热门专题
