精彩回顾 | 运维行业饕餮盛宴,GOPS上海站完美落幕,MoPaaS-SRE正式发布

申城寒潮来袭,然而在昨日第八届全球运维大会上海站暨首届金牌运维峰会的会场,参会人群依然热情不减,为大会收官划下完美句点。作为运维届最具影响力的盛会,本次现场参会人次突破以往,另有大量朋友通过线上直播观看。数万运维人员齐聚一堂,共襄盛会。

围观听讲的工程师们

MoPaaS的SRE产品负责人陈赤榕受邀在大会第一天的金牌运维专场上发表题为《技术运营:云服务可靠性工程》的演讲,同时借此盛会,官方正式发布MoPaaS-SRE这一雕琢已久的新产品,以下为演讲实录:

从事运维这个行业差不多有18年了,从一线的工程师到管理者,从甲方到乙方,从硅谷到国内,处理过大大小小无数多生产线的事故。今天我想跟大家分享一下我对这个行业的理念和实践,并且如何将其融入到我们现在MoPaaS-SRE的产品当中的。

先介绍一下MoPaaS,我们是一家做PaaS解决方案的公司,主要客户包括金融、智能制造和教育行业,我们应该也是市场里面极少能够同时提供Cloud Foundry和Docker两种最主流PaaS平台的公司。我是MoPaaS-SRE这一项目的负责人,今天也是想要借此机会,向大家发布我们的运维新产品SRE。

运维真正的理念是技术运营

先讲运维的理念,其实我本人不是很喜欢“运维”这种简单的表达方式。因为在硅谷,这个职位是被称为Technical  Operations ,就是技术运营。后来衍生出了DevOPS和SRE。商务运营和技术运营结合在一起,形成一个完整的运营,也就是Operations,最终将产品形成一个对客户有价值的服务。在这个层次上,运维这个词就更不能准确的体现Operations的责任和贡献。技术运营Technical  Operations是对这个行业比较准确的描述。

技术运营的两个角度:DevOps和SRE

技术运营的两个角度

那么,到底什么是Technical  Operations?分为两大部分,一个是DevOps一个就是SRE。大家都知道DevOps的概念是从2008年开始被提出来,而SRE是在谷歌的一本书(Site Reliability Engineering)里被大家广泛认知。很多人会认为这是两个一样的概念。但我想说,他们的目标虽然一样,侧重点却有着非常大的不同。

 

DevOps理念的提出者是开发人员,他们的关注点会在CI/CD,发布自动化等方面。而SRE呢?如果你看过谷歌的书就会发现,虽然谷歌的作者们也是从研发转岗过来,但一旦他们进入真正的生产线运营之后,注意力就会全部放在服务可用度,事故快速处理、日常监控等方面。

另外,DEV和OPS两个部门KPI不一样,DEV部门的压力主要来源于销售和市场对于产品功能需求,开发人员希望在最短的时间内去deliver更多的feature到customer;OPS人员的压力却在于产品的稳定性。虽然大家都希望DEV和OPS能够一体化,实现产品的快速上线和稳定运行,但是这两个目标实际上在很大程度上是矛盾的。比如,变更管理。我们希望飞机稳定飞行,那就不希望在飞行时,做很多维修或变动。所以我不太认同这两个部门的概念能调和在一起,因为他们KPI的方向是不一样的。

我看到很多公司里面,DEV和OPS部门分分合合。这其实就是像DEV和QA的关系一样。我认为最好的解决办法就是让他们独立运作。短期看,部门之间的边界效应会影响产品deliver的效率。但是长期看,独立部门的运作就会有互相的check and balance,避免大的错误。最终产品质量稳定性和go to market 的速度会提高。

而SRE和DevOps也就像太极双仪,互为平衡。MoPaaS的SRE产品侧重点就在生产线的运营这一方面

SRE应该是管理+技术的一个双维

MoPaaS-SRE提出了全新的双维模型理论。我们认为,最好的SRE应该是“管理+技术”的一个双维。

“技术+管理”的双唯模型

SRE的目标,就是技术运营的服务可用度、用户体验、成本效益和生产效率这四大目标。

从技术维度讲,是指通过监控技术、自动化技术和工程这些技术达到我们的目标。

从管理维度讲,就是事故管理、问题管理、容量管理和发布管理。

其中横穿这两个维度的就是自动化能力、数据运营能力和安全能力等。以数据能力为例,一方面,技术数据要能够帮助到商务,做客户和市场的分析;另一方面,监控及其数据就要求非常有效和高效,能够帮助我们快速对问题进行定位。这就是一个双维模型。

双维模型之管理

管理这块,为了给大家一个更深的印象,我们再分享一个例子。

大概是2001年的时候,我在WebEx,也就是现在Cisco云计算部门的前身工作。一上来,就处理了一个因为管理问题造成的事故。那是一个系统工程师(SA)的误操作。当时,他前面有两台机器,一个是lab机器,一个production(生产线)的机器。他当时在准备晚上做patch,所以白天准备好之后,就去关机器。原本应该关那台Lab的机器,但他却把生产线上的那台机器关掉了,当时一下子就crash了所有在线上的会议。当时,生产线机器和lab机器在系统标识(system prompt)上面没有任何区别,SA一忙起来,根本无法区别不同的机器。这就完全是一个跟技术没有任何关系的事故,根本上就是管理问题导致的。

而今年年初GitLab也犯了一个同样的错误,一个SA误操作删掉了数据。大家可以想象,过了十几年之后,同样的问题还在发生,是多么令人挫折的一件事情。工程师们常常重技术,轻管理。所以说管理这个维度一定是大家需要特别关注的。

再谈一谈管理理论框架,我们从电信时代发展到云计算的云时代,其实已经产生了很多比较成熟的框架,如,eTom, COBIT,6-sigma,ITIL这些大家都耳熟能详。但是公司真正落地的却不多。这是为什么呢?我曾经非常认真的跟行业内很多公司进行过探讨,反馈的主要问题在于流程太重,过于固化

我们曾经向一家大型互联网金融公司推荐过我们设计的轻量级的ITIL流程。非常好用。但是甲方老板就说,我们公司这么多年一直快速发展,自己的流程也很有效,虽然有改进空间,但是为什么要全套照搬你们的流程呢?,而且你们觉得好的东西,也不一定适用我们。

这句话就让我反思了很久。就是说我们做管理到底要管什么。我们做出来的东西不应该是去约束对方,而是需要一个开放式的管理平台,这个平台能够包容万象,同时承载最好的理念在里面,而这个理念可以来自甲方,也来自乙方。

秉承这个理念,我们SRE开发的第一个平台就是管理平台,这是一个开放式的平台,用户可以像使用Visio一样,把流程和步骤通过拖拽的方式随意画出来,然后自己制定表单。设计理念就如我刚提到的,管理平台可以承载各种各样好的管理理念。同时这个管理平台也是一个业务平台,它可以跟SRE操作平台互相调用,形成一个真正的运营业务管理。

双维模型之技术

接下来我讲的是技术部分。运维界里大家都在谈自动化。而自动化的难点是什么?我曾经跟一个甲方的老板聊天,我说我们的系统很厉害,自动化很好,一个人工作10天的事情能在一个小时搞定;一个人平时管理5台机器,现在能管理5000台机器。然后他就问我现在的风险是什么。

这是一个非常好的问题。自动化实际上是一把双刃剑,在低效率的情况下,管理5台机器时的误操作可能宕了2台机器;但是如果管理5000台机器的情况下,一个误操作指令,可能就宕掉2000台机器。因此,自动化最核心的部分就是控制。其实就像在座的每一位,你们手里应该都有几十个到上百个自动化的脚本,但怎么去控制就是一个自动化工作中最核心的部分。

自动化操作的多层调度

我们SRE的开发的第二个模块,就是自动化操作平台。我们在自动化操作里面使用了三层架构。第一层是一个脚本库,种类各异的script;然后,同一个脚本可以用在不同的机器上面运行,我们叫做任务assignment,这是第二层;这个任务可以安排在不同的时间点执行,这个叫做作业task,这就是三层结构。

这三层带来了两个优点,第一个优点是可以非常灵活的进行扩展,第二个优点是,它可以在多个系统上进行控制,你的脚本、作业、任务,都可以控制。同时,这个自动化的操作平台跟我们前面所提到的可自定义的开放式的管理平台融合在一起,可以从管理流程上控制这些脚本执行,来防止自动化的失控。

MoPaaS-SRE平台的正式发布

洋洋洒洒讲了这么多,今天真的是一个非常难得的机会,大家能够聚在一起共同探讨,我也想借这个机会正式发布我们MoPaaS-SRE平台。

我们MoPaaS-SRE产品是以技术+管理的双维为基础,是围绕着可用度,成本,效率和体验这四个目标而设计和实现的。这一期提供了包括管理模块,自动化操作模块,还有一个轻量级的CMDB模块在内的3个系统。第二阶段的监控等模块我们会尽快发布,敬请期待。

我们的产品设计的背景是星辰大海,用12星座来作为我们各个子系统的logo。这样的设计想法是来自“银河英雄传”里的开篇之言:“我们的征途是星辰大海”。我希望我们的产品也是能做到业界的一流水准。

MoPaaS愿景

我们希望MoPaaS-SRE的这套解决方案,能够不仅在互联网领域快速增长,也可以在传统行业,包括制造、化工、电信等得到更多更好的应用。

 

以上,谢谢大家今天的到来。下面是我们SRE公众号的二维码,欢迎关注!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>