80%时间在灭火，普通工程师如何摆脱重复劳动？，80%灭火

80%时间在灭火，普通工程师如何摆脱重复劳动？，80%灭火

阿里妹导读：自从无人化运维离我们有多远？阿里智能化运帷平台深度揭秘文章发布以来，就引来了众多运维从业者的关注，大家不禁思考，无人化运维离我们有多远？我们如何成为运维领域的专家，不被淘汰？阿里巴巴运维中台技术专家宋意，整合了阿里云效2.0运维产品StarOps，与你分享如何利用工具把人从日常重复工作中解脱出来，向专业垂直领域纵深发展，逐步成长为领域专家。

从传统运维OD分离转型到新型运维DevOps，不是简单把运维丢给开发就可以了，需要先把运维的工作工具化，实现开发可以利用工具自助完成，DevOps强依赖运维工具的支持。工具的落地也不是一蹴而就的，需要结合企业实际情况逐步建设，第一步先完成标准化，如Java类应用一套标准、PHP类应用一套标准，标准化之后才能使用工具自动化，智能化的核心是数据，自动化沉淀了数据才能做智能化，三步需要逐一实现。

StarOps

云效2.0涵盖项目协作域、研发域、测试域、运维域，为企业提供一站式研发协同服务。其中运维域由StarOps负责。StarOps定位一站式运维平台，资源、配置、部署、监控、运行，覆盖应用运维完整生命周期，具备基于混合云的应用运维无人值守解决方案以及自动化、数据化、智能化应用运维解决方案。阿里在运维领域沉淀多年的专家经验和能力全部集成于此，目标是通过平台使用户直接拥有运维专家的能力。

产品体系由八部分构成：CMDB、发布、监控、堡垒机、主机运维、故障管理、运维大屏、运维通道。不管公有云、专有云还是两者的混合云，通过运维通道屏蔽底层环境差异，实现上层应用运维统一管控。

运维通道

运维管控通道是服务器自动化运维的基础，所有操作最终都需要落地到服务器上执行，可以细分为三块：

1. 命令通道：向服务器下发命令并执行，如ssh $ip $cmd
2. 文件通道：把文件分发到服务器上，如scp/rsync/wget
3. 数据通道：解决数据上行问题，如在脚本或命令执行完成后回调一个地址上报结果。

在服务器规模较小时，用上面提到的方法一般可以满足需求，不过随着规模的增涨，对安全、效率、稳定都会提出更严格的要求。用SSH通道时需要打通一台机器到所有服务器的认证，如果这台机器被黑客拿下向所有机器下发rm -rf，后果可想而知。

阿里自研的运维通道支持百万级规模服务器管控，支持二层/三层架构与容灾部署，1分钟可以操作50万台服务器，在内部每天有上亿次的调用，安全方面全链路加密签名、支持账号级别的命令映射，Agent经过淘宝、天猫、支付宝、阿里云等阿里生产环境业务真实验证，稳定性、安全性可以得到有效保证。运维通道与CMDB可以形成联动，实现数据的自动采集，保证CMDB数据的准确性与一致性。

CMDB

CMDB是运维的元数据中心，拥有绝对权威性，一个公司只能有一份。保存的数据有两个特点：被大部分运维场景依赖、相对静态一次维护多次消费，在阿里内部实践中数据归为两大类：

第一类：资源信息

传统资源有服务器、网络设备、IP段等，每种资源又有很多属性，如服务器的属性：SN、IP、主机名、OS、机房、机架、CPU、内存等，对于一台物理机而言SN、CPU、内存基本是永远不变的，OS可以随时重装，搬迁后机房信息也会变掉。使用云后资源类型又有OSS、RDS、SLB等，云资源的生产、销毁等管理操作也会集成进来。属性的变更应当通过外部系统或流程自动化触发，如OS信息应由装机系统维护更新、机房信息只能通过搬迁流程修改。

第二类：业务拓扑

也叫产品线，体现的是业务组织方式，例：BU/事业部->业务架构域->产品->应用，可以一级也可以多级，根据业务规模灵活调整。应用也有非常多的属性，像状态、等级、owner、开发负责人、运维负责人、代码库、开发语言等。多级时最上级一般与组织架构对应，增加子节点需要上一级审批。

CMDB保存着完整的资源与业务拓扑信息，通过资源与业务的关系，可以清晰了解各个业务使用的资源信息，资源属性信息再开放到其它系统消费，当拥有完善的基础信息后，基于场景的运维将会非常方便，例：

1. 把服务器监控项配置在产品或应用上，新增服务器将默认拥有监控。
2. 通过业务拓扑中的应用开发负责人判断谁有权限进行发布。
3. 服务器默认为运维负责人授权，其它人登录需要运维审批。

发布

互联网时代产品迭代速度直接决定产品竞争力，最近有机会接触一些传统企业，运维几乎都是贴身为开发服务，发布按开发写好的文档一步一步操作，只是作为操作工毫无价值与成就感可言。

几年前在支付宝的时候发布也很痛苦，发布窗口提前几个月规划好，基本一个月一次，发布日当天一大早到公司，确认系统owner到位后开始发布，每个应用做完beta发布都要群里吼声，由owner确认后才能继续发，最怕发到一半出意外回滚，因为应用之间有先后依赖回滚就是整个链路，从早发到晚是常态，真心体力活。

从一月一次到一周一次，再到现在几乎开发随时想发就发（核心系统还是要控制发布节奏），发布系统与业务系统一起持续完善优化才有的今天，随时可以发使得业务需求可以快速上线，线上缺陷能够得到及时修复，有效提升交付效率。

发布模式有很多，如蓝绿发布、滚动发布、灰度发布等，这里不再对名词做解释，采用哪种模式与公司实际情况有直接关系，但不管哪种模式背后解决的问题都是不要出故障，即使有也要将影响控制在最小。

目前大部分发布工具解决的是把应用包发到线上的问题，不要出故障基本靠人为登机器查日志或者看监控。不过人工检查难免会遗漏，或者有时候过于自信觉得改动小肯定不会有问题，最终可能还是产生了故障。所以我们目前正在做无人值守发布。当一台机器发布完成后自动关联分析监控数据，包括基础监控(cpu/mem/load)、应用监控(jvm)、中间件监控、业务监控，如果检测到明显异常则直接拦截停止发布，在监控项足够完善、数据足够准确情况下无人值守发布完全可以做到人工零介入，提交代码自动测试、自动发布，相信这一天很快就会到来。

阿里的发布系统在内部能够支撑日均10万发布量，可灵活定义发布流程满足个性化部署需求， java、nodejs、python、php等多种技术栈的自动化发布我们都能够支持，通过无人值守、发布自愈等智能化发布部署能力保证代码变更安全，有效降低线上故障。

监控

监控作为线上运行的“眼睛”，能帮助业务快速发现问题、定位问题、分析问题、解决问题，为线上系统可用率提供有力保障，通过利用率数据的分析，帮助业务精准控制运维成本。

支付宝在2010年监控采用的开源软件nagios+cacti，随着业务的不断扩张服务器越来越多，监控项调度延迟越来越严重，调高检测频率、换最高配物理机、把多台nagios组成集群、对nagios深度调优等还是无法支撑业务的发展，加上开源软件对应用以及业务监控的缺失，所以最后不得不走上自研的道路。

阿里的监控规模早已达到千万量级的监控项，PB级的监控数据，亿级的报警通知，基于数据挖掘、机器学习等技术的智能化监控将会越来越重要。监控系统是一整套海量日志实时分析解决方案，以日志、REST 接口、Shell 脚本等作为数据采集来源，提供设备、应用、业务等各种视角的监控能力，利用文件传输、流式计算、分布式文件存储、数据可视化、数据建模等技术，提供实时、智能、可定制、多视角、全方位的监控体系。主要优势：

1. 全方位实时监控：提供设备、应用、业务等各种视角的监控能力，关键指标秒级、普通指标分钟级，高可靠、高时效、低延迟。
2. 灵活的报警规则：可根据业务特征、时间段、重要程度等维度设置报警规则，实现不误报、不漏报。
3. 管理简单：分钟级万台设备的监控部署能力，故障自动恢复，集群可伸缩。
4. 自定义便捷配置：丰富的自定义产品配置功能，便捷、高效的完成产品配置、报警配置。
5. 可视化：丰富的可视化 Dashboard，帮助您定制个性化的监控大盘。
6. 低资源占用：在完成大量监控数据可靠传输的同时，保证对宿主机的CPU、内存等资源极低占用率。

主机运维

服务器单机操作、批量操作、系统配置的管理，我们把服务器日常运维操作全部集中在此，功能包括：

1. WEB终端：独创WEB终端可嵌入任何Portal，多种安全加密机制实现免SSH一键登录服务器，提升日常运维效率。
2. 文件分发：月均10亿次分发量，服务稳定性99.9999%；具备断点续传、动态压缩、智能IO流控等超强能力；同时在容器镜像层级预热，超大文件分发，窄带、跨洋、远距离传输方面具备世界级竞争力。
3. 定时任务：最小粒度支持秒级且支持随机，避免同一时间集中执行影响业务。支持按集群配置定时任务，新扩容服务器默认自动添加。
4. 插件平台：统一管控服务器的通用运维脚本及Agent，支持自动安装、自动升级、进程守护。

堡垒机

堡垒机是进入生产环境的第一道屏障，阿里自主研发的专业级堡垒机系统，实现了集中访问控制、多因子验证、边界管控、操作实时记录、过程录屏、容灾容错、高危审计、命令阻断等功能，实现对人员操作过程的全面跟踪、控制、记录、回放；符合安全审计，合规，政审，认证等要求，广泛应用于阿里集团各业务生产管理(含阿里云、蚂蚁金服)。产品特点：

1. 专业级堡垒机，满足访问集中管控，运维操作命令记录、过程录屏，高危命令识别与拦截阻断等，满足对于生产网用户操作行为监测与审计需求。
2. 软件部署简单灵活，无硬件依赖，达5000人同时在线高承载，超强合规保障，符合美国上市企业SOX404审计要求和ISO27001信息安全认证要求。

故障管理

IT变更与事件管理，与运维平台天然打通，监控异常事件可一键转工单跟进，主要功能：

1. 事件：支撑客户、内部反馈线上业务异常，技术支持跟踪、处理、解决的流程支持和管理。
2. 故障：线上故障进行记录、通报，并记录review内容及改进措施。
3. 问题：故障Action或需要长期解决的问题跟踪，可以与评审流程联动。

运维大屏

综合CMDB、监控等数据，为企业提供定制可视化大屏服务，以大屏的方式在指挥中心展示业务运行状态，辅助指挥决策，大屏也是运维自动化效果展示的最佳窗口。

点击文末“阅读原文”，可了解更多“云效”信息。在日常工作中，你有哪些工具或方法，可减少重复劳动、提升效率？欢迎在留言区一起交流～

你可能还喜欢

点击下方图片即可阅读

阿里工程师的买房装修记

双11备战核武器：全链路压测

阿里又开源了一项自研核心技术！

关注「阿里技术」

把握前沿技术脉搏