实现开发可以利用工具自助完成

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.
灵活的报警规则:可根据业务特征、时间段、重要程度等维度设置报警规则,实现不误报、不漏报。

  1. 管理简单:分钟级万台设备的监控部署能力,故障自动恢复,集群可伸缩。
    4.
    自定义便捷配置:丰富的自定义产品配置功能,便捷、高效的完成产品配置、报警配置。
  2. 可视化:丰富的可视化 Dashboard,帮助您定制个性化的监控大盘。
    6.
    低资源占用:在完成大量监控数据可靠传输的同时,保证对宿主机的CPU、内存等资源极低占用率。

主机运维

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

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

堡垒机

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

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

故障管理

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

1.
事件:支撑客户、内部反馈线上业务异常,技术支持跟踪、处理、解决的流程支持和管理。

  1. 故障:线上故障进行记录、通报,并记录review内容及改进措施。
  2. 问题:故障Action或需要长期解决的问题跟踪,可以与评审流程联动。

运维大屏

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

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

你可能还喜欢

点击下方图片即可阅读

阿里工程师的买房装修记

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

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

关注「阿里技术」

把握前沿技术脉搏

相关文章