2013年，我加入了聚美优品。 当时成都队只有四五个人，负责日志检查等辅助系统的日常运输。 随着公司规模的逐渐扩大，一些重要业务转移到成都，对成都团队来说是非常大的挑战。 我逐渐认为业务开展最初是手工操作，应该有满足我们工作的平台，所以我们做了运输平台。
本文围绕平台中的自动化进行介绍。 当然，我们是一个小团队。 不足的地方请指出。
传统运维带来的漏洞说到运维自动化，前两年还是个热门话题。 首先，谈谈传统运维的弊端和运维自动化的意义。 我们的日常运输工作比较繁琐，一些研发同学会经常让我们在服务器上查日志，今天在线上做点东西和他们一起下班布置环境。 这些琐事充斥着我们的大部分工作，所以整个运输部门的工作效率不高。
还有一个关于标准的问题。 这个问题给我们带来了很大的损失。 早期的美国国内，由于引进习惯千差万别，一些项目无法维持，出现了谁工作、谁死的问题。 2014年北京方面负责订单的同事辞职，将订单系统的运输业务移交给成都方面。 我们当时面临着“双十一”的上线。 我们经常熬夜做两三个晚上。 相当痛苦。 传统的运输模式还存在效率问题。 在服务器上运行命令和部署程序效率低下，非常容易出错，出现错误后仍无法很好地排除问题，从而浪费大量时间。 效率问题涉及成本问题。 我们的云服务是从提供商那里购买的，需要花很多时间准备运行环境、上下线。 这对公司来说是不小的支出。
我们想按时下班，和家人一起做点什么。 我们的运输工程师，电脑喜欢用多个显示器，窗口管理器也喜欢用瓷砖。 这看起来像牛，但做着庞杂的工作，没什么效果。 我们只要建立自动化的运输平台，就可以解决日常面临的这些问题。
运输自动化的进化现在谈谈运输自动化的进化过程吧。 一开始没有做这些事情的特殊工具，后来有了Bcfg2、Puppet、SaltStack等自动化运维的工具，最后做了运维的自动化平台。
图1运维自动化发展历程
说起工具，确实提供了提高效率的方法，但也存在其他问题。 例如，在聚美初期采用bcfg 2结构作为服务器部署的工具，由一两个核心的运维人员在主机器上以命令行方式执行操作，效率低下，随着运维工作量的增加，所有的工作都会损失给一两个人，很不方便。 但一旦放开权限，对运输业务的权限没有限制，也不利于审计。
另一个问题是，在结构运行时执行输出可能无法很好地显示屏幕。 例如，如果运行20台，则可能有19台实际正在运行。 如果有一台没有运行，输出内容会闪烁，无法顺利反馈。 此时，如果将机器联机，则会发生错误。 我们有必要在平台上避免这个问题。
资产系统要说运维自动化的基础运维自动化，我有一个必须说的。 那是我们的资产系统。 这是运维自动化的基础。
资产系统为运维提供基础信息。 例如，机器属于哪个项目，该机器在什么环境下运行等。 它还具有描述计算机的属性，如IP地址、IPMI管理地址、计算机类型、承运人信息、机柜和连接的交换机端口。 如果这些信息在机器上出现问题，可以让机房调整为快速找到机器的位置。 也可以根据这些信息盘点资产。
资产系统的信息包括物理信息和逻辑信息。物理信息包括硬件信息和网络连接的信息，是实实在在存在的信息；逻辑信息需要人工填进去，自动化运维的时候用得到。
图2资产系统中包含的信息
堆栈，自动运输工具
描述资产系统，也谈运输自动化工具——SaltStack。 无论是手动还是使用自动化工具，您都必须熟悉服务器操作系统配置和基本服务配置。 系统优化包括sysctl.conf、ulimit.conf和网卡软中断绑定。 此外，还修改了计算机标准化，包括计算机locale、服务时区和yum(apt )配置。 通过标准化这些内容，可以统一服务器操作环境，并避免环境差异带来的各种奇怪问题。 此外，还需要配置服务器的基本服务，每个服务器都必须运行自己为每个企业创建或定义的程序。 例如，美国内部有统一登录认证服务，系统监控程序需要安装并部署在服务器上。
除了系统配置和一些基本服务外，您还需要熟悉各个业务服务的配置。 例如，假设您包括负载平衡器。 例如，LVS、Nginx。 接下来是与JAVA和PHP等相关的业务。 Tomcat、FPM、PHPServer等。 PHPServer是我们内部的RPC服务，所有业务的主线都用这个。
通过将SaltStack用作自动运维，可以简化这些服务器的配置工作。
一旦自动化运输平台的运营逻辑具备了资产系统、运输自动化工具两个基础，就开始构建资产系统与运输自动化工具相结合的自动化运输平台。
图3自动化运输平台的运营逻辑
资产系统为平台提供了基础信息，资产系统具有SaltStack和信息交换流程。 例如，前面提到的一些逻辑信息将被导入到SaltStack的grains中，一些物理信息需要通过SaltStack提交给资产平台。 自动化平台是SaltStack的
API去执行SLS文件，执行完了之后，通过SaltStack的returners调用运维平台的API将执行结果返回回来。SaltStack是通过grains获取资产系统的信息的，在SaltStack的客户端salt-minion启动之后，SaltStack的master会收到一个“minion_start”的事件，可以在事件上面绑定一个sync_grains的动作，这个动作使得salt-minion资产平台拉所要的信息，把这些信息存到grains里面去。通过SaltStack初始化系统的时候我们会引用一个SLS文件，这个文件的内容是将SaltStack的grains里面保存的信息提交到资产平台。
现在来说说平台调用SaltStack执行的逻辑。一种场景是SaltStack代码要管理多个项目，常规的做法是每个项目定一个SLS文件，定义需要初始化的内容，这种做法也是可以的，但是对平台的开发没那么方便。我们的设计是的是无论多少个项目，根据配置文件来表述这些项目需要初始化的服务，这样子平台的话逻辑会变得相对简单。比如说有一个项目，我们把这个项目要定义的一些东西放到配置文件里面去，比如说它的项目属性、发布目录，还有就是要初始化什么样的服务，把这些东西通过配置文件组装起来。初始化的时候不用关心具体是什么项目，都调用统一的入口文件deploy。在deploy.sls做一些逻辑，按照配置文件初始化好各个服务整个项目就初始化好了。
SaltStack反馈执行效果的逻辑刚才讲了去平台调用saltstack的逻辑，现在讲一下saltstack把结果反馈到平台的逻辑。
图4 自动化运维平台的反馈逻辑
这个很简单的，刚才提到行的时候可能会有一大堆信息输出到屏幕上，没办法跟踪、定位具体哪一个地方出错了。我们就把执行的结果，通过调用平台的API返回到平台里面，平台把返回的结果存储到数据库里面去，后续可以在界面上可以看到每一步执行的详细结果，并且可以根据执行的一些信息做一些审计的工作。
SaltStack部署方法运维自动化平台以稳定性为第一原则。我们之前老的系统为每一个项目新建一个用户，通过这个用户来运行FPM进程，而咱们新的平台一上线的时候，每个跑FPM的机器用户名都是一样的，执行用户的改变就导致之前写的日志没法写入了，出现了业务的故障。所以之后我们将老的系统迁移到新的自动化平台的时候都需要非常小心。
简单介绍一下SaltStack用户部署的方法。部署SaltStack的客户端salt-minion时候会有一个KEY接收的过程。传统的做法是是用“salt-key -L”命令看一下哪些机器已经注册到平台中，然后再使用“salt-key -a”把key接收进来。在咱们的平台中这个过程是自动的，我们通过reactor的机制来实现的。具体为：机器注册进来之后有一个“salt/auth”的事件，我们把给个事件绑定一个动作，然后在这个动作里面检查key是预定义的来决定是否让这个机器来注册到salt-master上面。如果salt-minion的机器配置目录被删除了，salt-minion重启之后不会注册到salt-master 上面。这时我们只需要在salt-minion的机器上重新跑下配置salt-minion的配置脚本，将统一的KEY下发给它就可以保证salt-minion能够重新被salt-master接受。
打造运维自动化平台遇到的问题说一下初始化业务环境的时候，遇到的一些问题。
图5 打造运维自动化平台过程中遇到的坑
先说资产信息的频繁变更，比如说这个机器可能觉得数量比较多之后，将机器挪到其他项目上去，此时salt-minion 里面记录的grains还是之前项目的信息。出现这种情况需要我们在每次对机器执行初始化等操作的时候先给他绑定同步资产信息的动作。
还有一个是大量添加机器的删除的问题，比方说大促的时候两千台机子，大促完了之后会把机器给下掉，此时salt-master 接收的机器不会被删除，会有很多冗余的信息。我们目前想到的办法是通过cron把salt-master上面的机器列表拿出来ping一下，如果能ping通的就保留在salt-master上面，不能ping通的机器则使用“salt-key -d ”命令给删除掉。还有是一个“max open file”的问题，通过saltstack重启的服务，重启之后进程的“max open file”变成了默认的1024，此时我们需要定制下这些服务的启动脚本，玩命的手链加入“ulimit -n 65535”等内容。
展望最后，自动化运维平台后面会往容器或者是微服务的方向过渡，而传统的自动化方式对我们来说就没那么重要，我们现在也在做这方面的工作，因为我们公司内部有一些使用FPM的项目，对单个节点效率要求也不太高，放在容器里面运行比较合适，我们也在使用Kubernetes加上Docker做我们下一步的部署方案，但现在只是一个初期阶段。
声明：本文来自「又拍云主办的Open Talk——DevOps与持续交付实践」的演讲内容整理。PPT、速记和现场演讲视频等参见“UPYUN Open Talk”官网。
嘉宾：沉静的日记本，聚美优品高级运维工程师。
责编：心灵美的小松鼠，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的xqdl架构师，欢迎架构师加微信qianshuguangarch申请入群，备注姓名+公司+职位。