图：任意门运维负责人尤首智
编者按：2021年12月10日，在阿里云云上架构与运维峰会上，任意门（Soul）运维总监尤首智发表了主题为“Soul云上运维架构创新实践”的演讲，和大家交流了Soul云上运维方面遇到的问题、挑战以及在平台化建设过程中的经验分享。
尤首智曾就职于搜狐、奇虎、快手等知名互联网企业，一直从事运维架构、存储、DevOps相关的工作，是一名相关经验非常丰富的“互联网人”。2020年11月加入Soul之后，主要负责运维稳定性及平台化建设，推动DevOps体系落地。本文根据他的演讲整理而成。
一、Soul云上的问题与挑战
在加入Soul之初，我就面临着四个困难和三个亟待解决的问题：
第一、人力短缺。运维部门只有4名同学，研发线只有200个同学，对于一家年轻的公司来说，1：50这个比例是比较高的。
第二、无成型运维工具。工具是存在的，单点上看功能不完备，整体上看运维层面没有串联起来，这大大增加了运维成本。
第三、业务高速迭代。每周一个小版本，两周一个大版本，这与公司业务线的发展体系有关，而且Soul也在不断探索一些新的领域。
第四、基础架构的缺失。这导致接入和使用方式多种多样，每个部门保持自己独立的基础架构，这种工作形态同样也大幅提高了运维成本。
在这些困难下，我们认为，如何短期内提高运维效率，是Soul运维部门当时阶段首要解决的问题。因为只有提升了运维的效率提升，我们才有更多的时间去做更多的事情，包括提升业务的稳定性、更好地支撑业务快速迭代等。
二、运维效率提升
Soul对于运维提效制定了四个主要方向，同时也是我入职后落地工作的重要抓手：
01 解决云上效率问题
Soul在平台建设的过程中使用了大量的阿里云的PaaS产品，并且在日常维护中产生的工单较多，Soul将大量的工单处理交给了阿里云的同学，组成短期快速实现闭环的工作链条，这个给了我们更多的时间去梳理公司现状与问题，节省了极高的时间成本。
02 优化发布平台
Soul也是用了中小型标配的Jenkins、以及一部分阿里云EDAS产品能力，这两款产都不是一个完整的发布体系，都有部分功能缺失，于是我们就选择通过以下几个方面建设CI/CD体系：
◾ 发布周期：由于没有固定的发布窗口，大大延长了故障的时间，无法及时处理故障问题，降低了用户的产品试用体验。比如凌晨上线，到第二天上班才知道故障的发生。
◾ 完整迭代：从DEV环境到QA再到代码扫描，再到灰度最后到线上，完整的迭代周期串联是团队当初急需要做的。
◾ 发布效率：发布当时面临最大的问题是稳定性差，CI/CD一体执行，发布底层salt和ansible执行效率低下；首先我们需要将CI、CD分离；编译所需参数存储于CMDB中，打包动作逐渐脱离jenkins，将编译功能集成在发布平台中；CD部分去掉salt，全部替换为ansible api；
◾ 参与度：降低运维的参与度，提高研发与平台交互度，让运维有更多时间更多关注迭代内容、周期、发布次数等。
03 CMDB建设
CMDB是运维最重要的一个信息源，也是完整的运维体系的第一步。
Soul也将所有的信息源都写入到CMDB中，包括阿里云资产、自建应用信息、服务构建参数及组织架构人员信息。
存储相关信息的作用主要在于CI/CD、自动化运维、成本分析、报警、故障能够与客户端表现的直接关联。CMDB构建并没有在短期内一次性完成，是从阿里云的部分资产入手，最后到构建参数，逐步补齐。随着CMDB的逐步补齐，基础环境的标准化也在初步推进。
04 运维工单平台的0-1
Soul运维工单平台是运维对研发甚至是对公司唯一的入口。在此之前内，部均使用邮件方式沟通，但随之而来的是邮件丢失、延迟的等问题， 导致需求处理延误、因权限管理不清晰而有部分同学自行操作，继而发生各种问题。
Soul工单平台更接近云管控，逐渐替代掉阿里云控制台的权限，同时我们使用工单的方式逐渐的规范研发同学对中间件和阿里云底层资源的认知，主要分三个阶段：
阶段一：纯手工打造。工单平台抽象高频的操作和需求，但依然是人工执行。这个阶段的工单平台，更多仅像一个web入口，无太多自动化能力。
阶段二：人工决策，自动执行。这个阶段持续时间较长，工单需完成自动化能力补齐。
阶段三：自动决策，自动执行。将业务对资源的需求与资源类型/资源规格转化，常态化需求描述以及个性化需求描述，需要通过工单平台入口使得运维更加靠近业务。
到此阶段，在半年时间内，运维自身效率已提到提升，有了更多的时间参与稳定性架构改造，同时运维人员也更多的精力关注业务动向。
三、稳定性建设
01 面临的问题与挑战
Soul不能“挂”是整个团队最重要的OKR，原因是2020年Soul上过两次热搜，都是因为架构不稳定导致站点异常从而引发热议。
第二点是服务预警与快速恢复，这一部分是缺失的状态，导致故障发生后无法第一时间精准定位根因。
第三点是架构演进，Soul的业务体量在持续上涨，体量变大的架构演进是必然的。
02 故障定位与处理
稳定性的生命周期中，故障与非故障的时间占比是非常重要，非故障时间需要增加架构的稳定性建设、复盘、演练，才能让故障的时间占比下降，使业务的稳定性向着更加健康的方向发展。最近一年时间里，着重于稳定性建设时间，增加演练次数，下面也会着重分享稳定性改造的相关案例。
03 稳定性改造
在过去一年当中，稳定性建设方面，Soul大致进行了上图中的六个工作，我们将从中挑出三个较有代表性的方面展开分享。
改造1：监控系统的演进
2020年底，Soul的监控只有AMRS，虽好用但不适合Soul，比如IT治理没有做好，主机组+报警模板+报警联系人+组织架构+发送通知关联不起来，导致只有运维收报警，研发同学收不到。运维同学只能手动转发给研发同学进行处理。
在K8s平台方面，Soul当时使用的是Promethues。Promethues最大的问题是无成型web交互，查询及报警语句有相对较高的门槛。
到2021年3月，我们开始正式做监控治理，使用OpenFalcon进行底层云产品的监控，同时将公司内部的多套Promethues及阿里云的Promethues服务进行合并，统一Promethues数据源。这样公司里面只有两款监控产品：一个面向底层资源，一个面向K8s。
2021年6月，我们开始自研监控系统OWL，从名字“猫头鹰”上能看出来，我们希望它能代替运维同学在晚上值班。
OWL监控沿用OpenFalcon前端的页面，兼容Promethues数据，将Promethues的查询及报警语句抽象出来，进行格式化的展示，并添加报警功能。这一点类似于grafana的promethues插件部分，目前已经将所有的报警整合在OWL报警平台当中，同时也实现了信息采集及报警功能完善。
下一个阶段是报警网关，报警网关还需要拥有报警接手+解决+报警升级的能力，方便运维同学对问题的跟踪。随着报警逐渐的添加，报警的数量也逐渐在增长，也出现了报警信息被淹没的情况，为了方便运维同学对问题的跟踪，报警网关进入了下一阶段的迭代，报警接手+解决+报警升级，减少群里的重复性报警的同时又不会漏掉关键报警。
改造2：接入层改造
上图左侧架构是Soul 2020年的架构，右侧是最新的、改造后的架构。
左侧架构中，SLB对接ACK pod及ECS；优点非常明显，不会出现大故障，缺点则是可维护性较差，导致小故障不断，客户端表现的很多异常，大部分来自接入层。
右侧是新架构改造，统一接入层，开启ingress入口模式，优势是能够轻松实现全链路的把控与追踪以及成本的优化，统一的高防与WAF接入。
改造3：MySQL切换PolarDB
MySQL切换PolarDB是2020年，SOUL与阿里云深度合作的第一个项目，改造的背景是MySQL分库分表机制有问题，磁盘与CPU不匹配，单实例已超过阿里云SLA标准，达到了6T的数据。
而Soul的业务场景是读多写少，同时团队也在考虑分布式DB，这两个特性与PolarDB与Soul的匹配程度非常高，团队人员用了1个月时间，将大于1T的30组MySQL实例，全部迁移至PolarDB，迁移后无论是在费用、稳定性及使用率多个方面均正向收益。
对于以上的架构的改造，对于Soul来说，不一定是最好的，但却是最实用的、短期内可以支撑业务的高速迭代方案。
四、未来方向
最后，分享一下Soul在2022要做的几件事情：
1、继续探索云上能力。对于Soul这样的中小型公司，底层技术能力部分其实可以依赖公有云，特别是Soul在做多方向试探的业务场景，可以借助公共云的帮助实现自有业务迭代。
2、私有的管理方式。对于公有云的基础能力，加上自定义的管理和接入使用方式，完全能够助力业务的快速迭代。例如RDS、Redis，可以把它当作一个实例；ECS则可以看作是一台物理机，通过这样的使用方式，来去掉IaaS层的压力。
3、产品的PaaS化。Soul团队也将深度学习阿里云的产品思维，将自有的PaaS产品做得更加产品化。
最后的最后，我希望致敬每一位运维人，致敬我们平凡中的不平凡。
点击大会官网，查看尤首智在峰会上的精彩演讲视频。