顺丰IT基础架构运维的焦虑与进化

经过大量的整理、梳理、配置、观测、调校工作,我们的运维团队花了半年多的时间完成了配置管理和监控系统的建设工作,完成之后,大家有了心清目明的感觉,心里也踏实多了,在此之后,我们的系统可用性比之前有了持续、大幅度的提升.经过一年多的努力,我们故障量下降到上一年故障量的一半左右,到目前,故障率可能只有之前的十分之一.

每年的双十一对资源的需求是喜马拉雅山形式的,突然飙上去,资源容量怎么办?我们根据监控系统采集到的数据推入容量预测平台,利用R语言结合历史数据和业务量建模,得到和业务量相关的系统容量模型,再代入当年双十一业务方对于业务量预测的结果即可得到双十一每个系统的资源容量要求体检进行准备.而真正进入双十一的时候,基础架构团队会相对轻松,公司的业务系统也可以做到平平稳稳度过双十一了.

4.4 新的焦虑

快递行业风云变幻,总体来讲近两三年快递行业服务单价都在下降,逆向对IT运营成本有增加了的压力.随着互联网的发展,业务形态更加多元化,而且业务的要求也越来越快,IT交付难度愈来愈高.初期的版本需求是一个月下一个版本,或者两周,而今我们部分系统已经是每周一个迭代.这些变化都要求基础架构需要更加轻和快.

而实际情况是基础架构是重资产单位,在整个IT运营成本中占比较高,另外之前采取专业分工的组织模式,也开始出现副作用,专业团队只站在自己的角度考虑问题,协同弱,沟通环节太多,效率低.专业壁垒已经形成,变成一个无法回避和逾越的问题,运维团队再一次陷入焦虑的循环.

5、加速-注重效率和成本

5.1 基础软件去商业化

全面拥抱开源,经过半年左右时间的预研、测试、研发框架实现,2015年开始,我们所有的基础软件实现了全开源,其中包括中间件、消息件和数据库等.开源以后,在软件许可和厂商服务方面的投入可以忽略不计了.

由于行业的特殊性,有些公司主要还是使用商业软件,而且需要使用大量的厂商服务资源,这种和厂商背靠背的运维模式,这种模式投入相对高,对厂商有一定的依赖.

开源以后,失去厂商背靠背的支持做运维,在开源软件的稳定性和性能方面必须掌握把控力,要深入掌握体系结构、功能、性能,部分和部件之间的关系,最好能够做到对?Bug?能够进行快速修复和性能优化,所以全面规模化的开源,需要形成自己的运维研发能力.

我们在导入?MySQL?的时候,本着“简单用”的原则,对不适合?MySQL?最佳实践的用法直接在数据库开发规范中进行明确约束.试点选择公司重点系统项目,我们的?DBA?团队和项目研发团队一起并肩作战,陪着研发一起走完了分析、规划、设计、代码、测试、调优、试运行一整套完整的过程,这个过程既是研发逐渐接受?MySQL?的过程,也是?MySQL?业界的最佳实践调校为顺丰的?MySQL?最佳实践的过程.从最终的结果来看,MySQL?更多的承担这数据容器的角色,业务逻辑绝大多的剥离到了数据库之外.

5.2 完善服务体系

全开源部分缓解了IT运营成本的压力,IT资源交付效率怎么办?最初我们新需求出来,只能做到15天后交付给需求方.后来经过架构师团队的努力,到一站式交付,通过流程梳理优化、工单系统导入,可以做到2~3天的交付,需求量较大的,最晚5天内交付.

之前做软件架构标准化改造和全开源,是自上而下的运动式的大跃进,运维和研发由于关注点的不同,目的也不完全一致,相互支持自然少不了,但相互理解方面到不得而知.为了增进理解,形成科技合力,基础架构运维团队提供了架构和 DB 设计服务,基础架构师和 DBA 直接驻点研发重点项目团队,和研发兄弟一起工作,提供专业能力的支持和问题的解决,实实在在的合作,几个项目下来,研发对运维的专业性的开始认可.

每次运维质量出现逆向波动的时候,回头看看?ITIL,检视管控点的缺失或松懈,多半都是执行的问题.ITIL作为一套成熟的运维治理法则,活学活用还是很有帮助.

5.3 日常工作自动化

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!