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

这篇文章给大家分享的是有关互联网运维数字化转型的示例的内容。小编觉得挺实用的，因此分享给大家做个参考。一起跟随小编过来看看吧。我们先从数字化转型说起，这几年整个行业或者整个大的环境上都在谈数字化。什么是数字化？在我来看，数字化就是一个企业的转型，可能会带来更快的效率，也会带来用户更好的体验。顺丰在前几年就在做数字化的转型。顺丰收件派件下单，这是大开发云主机域名家用得比较多的。这后面有很多的环节，包括分点部、陆运、中转、航空，这是物理上的路径。数据流更加复杂，有任务分发、路由分发和运单生成以及分发等等。我们这几年在做的事情就是把这些东西全部数字化和线上化，这些做好会对后续的路径规划、收派规划做优化。在人力成本上和运输成本上会有很大的节省。大家有没有留意到，在2017年之前所有用顺丰寄快递时，都会给你一张纸填寄货单。在2017年以后有变化了，顺丰做了一个融合项目，把所有纸质面单全部线上化，这就是现在所有的下单全部是扫二维码。这是业务发展趋势，从3月份到5月份是慢慢推广试运行的阶段，5到9月份的时候我们进行了全网快速的推广，把纸质面单全部替换掉，经过大半年的时间，现在顺丰所有的单量全部是线上化和电子化，到12月份该项目完结。对于整个项目来看是非常成功的，业务量也是一直涨。但是，这背后真的是这样一帆风顺的吗？3月份到10月份我们遇到很多问题，心里有苦不能说。上面这张图是拔河，这里面有很多人，类似于我们很多不同的岗位在一个项目当中或者在一个企业当中，运维、开发、产品、业务、推广，想把一件事情做好，第一件事情要做的就是目标一定要统一。因此以项目的维度来看，项目成功了我们就成功了。很多时候我们要打破一些部门墙，站在不同的视角或者把自己拔高到另外一个视角上去考虑问题。在项目初期我们就遇到了上述三个问题。这里面涉及到的不仅是纯技术上的，还涉及到一些组织架构流程，这会动到很多人长期以来的一些工作方式，是最麻烦的一件事情。这件事情要怎么搞定？其实很简单，就是你的老板。很多搞技术方面的不是很擅长利用我们已有的资源，如果碰到上面的问题，能够搞定的只有你的老板。你把你的老板搞定，老板可以给你很多的资源，才能把这件事情推动下去，不然只会卡壳在那。业务的压力推着你，把事情升级到老板并且说服他，让他帮你协调各种资源。爆发期也就是6月到9月份的时候，业务量从最开始的100万爆发到800万甚至1000万。这过程会出现很多问题，如性能问题，诡异的问题频现。在项目上前期是快速推广和试错，会忽略或者不太考虑一些技术上的风险，会留下有很多的技术债，这在整个业务量增长起来后频发的暴露出来。随着整个业务上的强制往上堆和业务量的持续增长，压力会传导到研发和运维，如果经常出现故障，每个层面面对的压力非常大。工程师文化就是专业、高效、开放、技术和担当，而且一定要认为这事我们是可以做到的。弹性是我们的一个救命稻草，随着业务量的增长弹性化扩展。弹性会分两个架构：一个是应用架构，另一个是基础架构。应用架构偏研发多一点，基础架构偏运维多一点。应用架构：基础架构：左边这个图是大体一个草图，用户端的请求过来会经过多种链路，如防火墙、网关负载均衡器、数据库等等。这一串长的链路要支持横向和快速扩容。横向涉及到技术标准的选型，快速是考验技术架构能力，在做推广的时候，服务器可能从一百台扩到上千台，能不能快速地交付还是需要人工去搞定，这就是快速。这是我们内部做的一个运维平台叫做维石。这里我们把很多资源分成很多层，最底下一层是硬件的，上一层就是虚拟化层，再到上面一层是一些组件层，专业组会把自己的组件层做成很多服务，再以编排的形式把它们全部串联起来，对外做交付，使得我们一些技术资源的申请可以很方便地实施。发布版本就涉及到灰度，很多敏捷迭代，会有一堆试错的在里面，版本上线非常频繁，我们的系统必须要支持灰度。对于业务有一个新的功能，灰度可以先切个10%或者5%的流量过去试用下。对于运维层考虑的东西更直观，切5%的流量和10%流量的时候，服务器的CPU负载有没有变化，如果流量切到20%，数据库的QPS比以前翻了20%到30%，可以立马发现问题并去解决。灰度的作用是给业务层试错，也给IT层留下了很大的空间去保证试错，如果出现问题我们能够快速地把流量切换回来。右边是一些灰度切换的规则，我们需要根据环境来切换、根据某个系统来切换，根据UIL服务串或者版本号来切换，规则做得越细，切换的力度就会越细，比较更加有保障。服务保护一般有三种模式：限流、熔断和隔离。监控分两个维度：一个是基础架构，一个是业务监控。左边是微服务化后的图，单体应用根据某种业务规则拆分得很细，分布在不同的节点上，一个微服务可能几百上千个节点，这时定位故障就困难了。我们需要链路追踪和非常完备的日志系统，才能很好地处理问题。对于微服务，有一些自己的观点。第一个是拆分的规则，拆分没做好好就会乱七八糟，最后就没有规则了。第二个是做微服务化需要组织架构的支撑，否则整个微服务化有点像打着技术的幌子，把简单的事情做得复杂化。任何系统是不能保证100%不出任何问题的，因此需要应急预案。在系统上做一些降级或者关闭的开关。在业务上最好也有线下的应急预案。演练就是针对应急预案是否有效进行验证。演练有两种环境：一种是直接在生产环境做，另一种是以模拟环境做。不管何种环境要有真实现场的感觉，要给参加演练的人压力。在演练的过程中也可以锻炼人员能力。业务有推广的需求，但是，服务器是否能够支撑的住并无把握，最简单的办法就是压测。压测分为三种情况：单接口压测、生产流量回放和模拟流量回放。单接口压测并不能准确的反应实际情况。这时需要生产流量的回放，把生产上面的所有操作全部拉下来，通过回放工具，对整个的环境做一些压测。回放工具必须要支持倍数上的回放，验证业务预估的量进行检测。也必须要支持能够自己造数据，现有的生产上面的流量数据还是跟实际推广时是有差别的。最开始做双活的目的有两个：第一个是保证系统更加可靠，第二个是容灾资源合理的利用起来避免浪费。做双活最麻烦的一件事情是需要把整个大部分的请求或者某一个单元中的请求尽可能在同一个机房中解决。跨机房的流量互串会出现问题，当某个机房宕掉了更加麻烦。还有Redis、DB等数据同步保证集群数据一致性的问题。通过kafka模块，根据分流规则分流到对应的机房里。以分流来说，我们必须支持用户请求到前端就能够做正常的分流操作。分流操作的做法是在APP或浏览器中，在http请求中打上城市代码的标记，根据这个标记规则进行分流将流量转发到对应的机房中。这个图是切换，如果某一个机房出现问题的话，我们在OPS平台上做配置，将整个流量切换到其它机房。运维的价值在哪里呢？第一个质量。质量无非是一些可用率、故障数、平均故障时长和用户满意率，这是运维必须要达到的。第二个成本。我们效果是拒绝浪费，有多个维度，资源是否得到充分合理的利用，容量评估是否数字化。流程是否与工具相结合。人力方面是否优化，把重复的劳动想办法替掉。第三个效率。传统型的运维要有所转型，往IT运营方向转型解决方案的提供者。另一个方向是往运维开发转型，从重复劳动中解放出来。第四个数据运营。运维人员是最了解整个公司的业务流程和数据模式的走势，要做很多数据方面的分析，包括数据运营能力方面的体现，为公司创造更大的价值。感谢各位的阅读！关于互联网运维数字化转型的示例就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到吧！

相关推荐: 电商订单履约系统：你每天都在购物，却对它一无所知

01订单履约概述4-OFC在什么环节出现？02订单拆分03金开发云主机域名额拆分3、对外服务本文转载自接蒜君相关推荐: 递归方法无法使用 return 返回值背景计算树级结构数据，终极节点。使用递归计算，获得3级子菜单问题无法获取子节点分析监控递归，是正确的。…