互联网运维数字化转型的示例-创新互联

这篇文章给大家分享的是有关互联网运维数字化转型的示例的内容。小编觉得挺实用的，因此分享给大家做个参考。一起跟随小编过来看看吧。

1. 从数字化说起

我们先从数字化转型说起，这几年整个行业或者整个大的环境上都在谈数字化。什么是数字化？在我来看，数字化就是一个企业的转型，可能会带来更快的效率，也会带来用户更好的体验。顺丰在前几年就在做数字化的转型。

顺丰收件派件下单，这是大家用得比较多的。这后面有很多的环节，包括分点部、陆运、中转、航空，这是物理上的路径。

数据流更加复杂，有任务分发、路由分发和运单生成以及分发等等。我们这几年在做的事情就是把这些东西全部数字化和线上化，这些做好会对后续的路径规划、收派规划做优化。在人力成本上和运输成本上会有很大的节省。

大家有没有留意到，在2017年之前所有用顺丰寄快递时，都会给你一张纸填寄货单。在2017年以后有变化了，顺丰做了一个融合项目，把所有纸质面单全部线上化，这就是现在所有的下单全部是扫二维码。

这是业务发展趋势，从3月份到5月份是慢慢推广试运行的阶段，5到9月份的时候我们进行了全网快速的推广，把纸质面单全部替换掉，经过大半年的时间，现在顺丰所有的单量全部是线上化和电子化，到12月份该项目完结。对于整个项目来看是非常成功的，业务量也是一直涨。但是，这背后真的是这样一帆风顺的吗？3月份到10月份我们遇到很多问题，心里有苦不能说。

2. 开端—目标

上面这张图是拔河，这里面有很多人，类似于我们很多不同的岗位在一个项目当中或者在一个企业当中，运维、开发、产品、业务、推广，想把一件事情做好，第一件事情要做的就是目标一定要统一。

• 业务。我们所有的都是都是为业务服务，给公司创造价值。如果一个做技术的人不了解业务，如何谈对公司创造价值。第一必须要了解业务，用业务的视角考虑问题，用业务的语言进行沟通。转变视角，把纯技术化的语言从业务视角跟项目团队沟通，这样大家能够站在同一维度上考虑问题。
• 运维要抛弃执行团队的概念。运维团队不是执行团队，不要把自己定位为一个执行团队，执行团队就是do，但它只是do，我们不是do这个动作，我们必须在整个核心价值链当中产生较大的价值。比如基础架构的评估、成本和安全上面花工夫，把这些价值体现出来。
• 关于成功。从不同的维度上看，成功会有很多个定义，以项目的角度来看，成功就是指这个项目是否成功。当公司相对大一点以后，会分很多个部门，每一个部门都有KPI，都要背一些指标，会导致大家的立场就不同了，出发视角也不同了。

  因此以项目的维度来看，项目成功了我们就成功了。很多时候我们要打破一些部门墙，站在不同的视角或者把自己拔高到另外一个视角上去考虑问题。

3. 初期—效能

• 流程。顺丰在前几年是比较重的体系，在流程上面会非常繁锁。一个审批需要找N个人，打N个电话说很多事情，时效很低下。因此需要在流程上进行一些优化，不然整个项目进度会拖慢。
• 组织架构。在传统行业，运维体系很大以后，会分成很多个个部门组织，比如基础架构会有中间件、有系统、有网络、有存储等等组，各个不同的专业组来负责专业领域，这时候就会面临一个问题，以项目视角看，涉及到各领域在整个沟通上会非常麻烦，排查一个问题一个异常或者一个故障，需要一堆人来搞定，效能上非常糟糕。
• 思维模式。运维跟开发的关系？是合作还是服务还是大家互相推诿的关系？这个我相信大家都是会碰到的问题。

在项目初期我们就遇到了上述三个问题。这里面涉及到的不仅是纯技术上的，还涉及到一些组织架构流程，这会动到很多人长期以来的一些工作方式，是最麻烦的一件事情。这件事情要怎么搞定？其实很简单，就是你的老板。

很多搞技术方面的不是很擅长利用我们已有的资源，如果碰到上面的问题，能够搞定的只有你的老板。你把你的老板搞定，老板可以给你很多的资源，才能把这件事情推动下去，不然只会卡壳在那。业务的压力推着你，把事情升级到老板并且说服他，让他帮你协调各种资源。

• 轻流程化。引入轻量级流程，减少很多的审批节点，并与工具相结合，让整个通道顺畅地跑起来。
• 全栈运维团队。打破现有的以专业组划分打造全栈运维团队，拥有所有的操作权限和操作职能，统一的对整个故障、问题和事件负责。会以整个视角考虑问题，打破部门墙和专业墙，组织扁平化。
• 思维转变。就是运维与开发的关系应该是一个合作的关系，而不是一个服务层面的关系，两者的地位是平等的而且目标是一直的。因此，我们的专业能力必须要得到很大的加强，与开发和产品做无边界的合作，才能在项目中产生较大的价值。

4. 爆发期—稳定

爆发期也就是6月到9月份的时候，业务量从最开始的100万爆发到800万甚至1000万。这过程会出现很多问题，如性能问题，诡异的问题频现。在项目上前期是快速推广和试错，会忽略或者不太考虑一些技术上的风险，会留下有很多的技术债，这在整个业务量增长起来后频发的暴露出来。

随着整个业务上的强制往上堆和业务量的持续增长，压力会传导到研发和运维，如果经常出现故障，每个层面面对的压力非常大。

工程师文化就是专业、高效、开放、技术和担当，而且一定要认为这事我们是可以做到的。

弹性是我们的一个救命稻草，随着业务量的增长弹性化扩展。弹性会分两个架构：一个是应用架构，另一个是基础架构。应用架构偏研发多一点，基础架构偏运维多一点。

应用架构：

• 第一个是无状态，就是集群上所有的东西都不要有任何用户的信息。
• 第二个是单点，单点问题就是木桶原理，一个木桶里能装多少水，不是取决于最长的板，而是取决于短的板。
• 第三个是分布式，分布式就是为了方便扩容。
• 第四个是是横向扩容，整个系统架构是必须要支持横向扩容。最麻烦的点在于数据库，一般的作法就是大表拆小表，大库拆小库，小库之间怎么分没有标准的做法，要根据本身公司的业务形态，比如根据程式，根据用户ID等等。数据库方案好前期就实现，后期再做对数据的迁移会非常痛苦。

基础架构：

左边这个图是大体一个草图，用户端的请求过来会经过多种链路，如防火墙、网关负载均衡器、数据库等等。这一串长的链路要支持横向和快速扩容。横向涉及到技术标准的选型，快速是考验技术架构能力，在做推广的时候，服务器可能从一百台扩到上千台，能不能快速地交付还是需要人工去搞定，这就是快速。

这是我们内部做的一个运维平台叫做维石。这里我们把很多资源分成很多层，最底下一层是硬件的，上一层就是虚拟化层，再到上面一层是一些组件层，专业组会把自己的组件层做成很多服务，再以编排的形式把它们全部串联起来，对外做交付，使得我们一些技术资源的申请可以很方便地实施。

发布版本就涉及到灰度，很多敏捷迭代，会有一堆试错的在里面，版本上线非常频繁，我们的系统必须要支持灰度。

对于业务有一个新的功能，灰度可以先切个10%或者5%的流量过去试用下。对于运维层考虑的东西更直观，切5%的流量和10%流量的时候，服务器的CPU负载有没有变化，如果流量切到20%，数据库的QPS比以前翻了20%到30%，可以立马发现问题并去解决。灰度的作用是给业务层试错，也给IT层留下了很大的空间去保证试错，如果出现问题我们能够快速地把流量切换回来。

右边是一些灰度切换的规则，我们需要根据环境来切换、根据某个系统来切换，根据UIL服务串或者版本号来切换，规则做得越细，切换的力度就会越细，比较更加有保障。

服务保护一般有三种模式：限流、熔断和隔离。

• 限流的概念就是当流量爆增，导致整体应用响应缓慢的时候需要做控制，把一些多余的请求或者无关紧要的请求过滤掉，虽然对用户体验不好，但是至少可以保证整体的系统稳定性。限流负载上面会有这个功能，也可以在自己的网关上实现。
• 熔断，现在都在谈微服务，各个模块拆得很细，必然造成很多东西不可控，一旦某个版本有问题就会导致挂掉，通过熔断服务在挂掉的时候不去请求直接返回，类似于降级。
• 隔离，在以前的做法会在一个大的线程池当中搞定所有事情，一旦某一类的请求出现问题会把整个线程池打爆。隔离就是把一个大的线程池拆开，不同类型的请求使用不同的线程池，每种类型的请求互不影响。

监控分两个维度：一个是基础架构，一个是业务监控。

• 基础架构的维度，如服务器的CPU、IO、MEM等，如果涉及到全国性的，还会用到一些波测的软件，包括APM。要做得更细的话，监控每一个方法服务调用的次数等等。
• 业务监控，基础架构的监控指标正常不代表业务上是正常的，业务监控必可可少，每一个关键核心链路上的服务请求，响应码，响应时间，都要定一个阈值，超过了触发报警，依据这些监控数据，通过算法做趋势或者预测预警，比如容量的预估。还有埋点，对整个链路进行完整输出便于问题定位。最后是业务链路，现有的系统都是互相之间调来调去，某一个系统出现问题，可能会影响到周边的业务，因此我们需要一个完整链路全景图。

左边是微服务化后的图，单体应用根据某种业务规则拆分得很细，分布在不同的节点上，一个微服务可能几百上千个节点，这时定位故障就困难了。我们需要链路追踪和非常完备的日志系统，才能很好地处理问题。

对于微服务，有一些自己的观点。第一个是拆分的规则，拆分没做好好就会乱七八糟，最后就没有规则了。第二个是做微服务化需要组织架构的支撑，否则整个微服务化有点像打着技术的幌子，把简单的事情做得复杂化。

任何系统是不能保证100%不出任何问题的，因此需要应急预案。在系统上做一些降级或者关闭的开关。在业务上好也有线下的应急预案。

演练就是针对应急预案是否有效进行验证。演练有两种环境：一种是直接在生产环境做，另一种是以模拟环境做。不管何种环境要有真实现场的感觉，要给参加演练的人压力。在演练的过程中也可以锻炼人员能力。

业务有推广的需求，但是，服务器是否能够支撑的住并无把握，最简单的办法就是压测。压测分为三种情况：单接口压测、生产流量回放和模拟流量回放。单接口压测并不能准确的反应实际情况。

这时需要生产流量的回放，把生产上面的所有操作全部拉下来，通过回放工具，对整个的环境做一些压测。回放工具必须要支持倍数上的回放，验证业务预估的量进行检测。也必须要支持能够自己造数据，现有的生产上面的流量数据还是跟实际推广时是有差别的。

最开始做双活的目的有两个：第一个是保证系统更加可靠，第二个是容灾资源合理的利用起来避免浪费。做双活最麻烦的一件事情是需要把整个大部分的请求或者某一个单元中的请求尽可能在同一个机房中解决。

跨机房的流量互串会出现问题，当某个机房宕掉了更加麻烦。还有Redis、DB等数据同步保证集群数据一致性的问题。通过kafka模块，根据分流规则分流到对应的机房里。

以分流来说，我们必须支持用户请求到前端就能够做正常的分流操作。分流操作的做法是在APP或浏览器中，在http请求中打上城市代码的标记，根据这个标记规则进行分流将流量转发到对应的机房中。

这个图是切换，如果某一个机房出现问题的话，我们在OPS平台上做配置，将整个流量切换到其它机房。

5. 延续—价值

运维的价值在哪里呢？

第一个质量。质量无非是一些可用率、故障数、平均故障时长和用户满意率，这是运维必须要达到的。

第二个成本。我们效果是拒绝浪费，有多个维度，资源是否得到充分合理的利用，容量评估是否数字化。流程是否与工具相结合。人力方面是否优化，把重复的劳动想办法替掉。

第三个效率。传统型的运维要有所转型，往IT运营方向转型解决方案的提供者。另一个方向是往运维开发转型，从重复劳动中解放出来。

第四个数据运营。运维人员是最了解整个公司的业务流程和数据模式的走势，要做很多数据方面的分析，包括数据运营能力方面的体现，为公司创造更大的价值。

感谢各位的阅读！关于互联网运维数字化转型的示例就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到吧！