6.0 KiB
云原生
目前形成云原生理解上的最大共识概括为4个核心要点：DevOps+持续交付+微服务+容器，即基于这”4件套”构建的应用我们暂且认为就是云原生应用了。同时可以享受到云端极为丰富的PaaS组件，如业务后续使用到的数据库、缓存、中间件、存储、CDN等等，并且具备无缝在不同云厂商间透明迁移的能力。
微服务架构为基础，构建的集代码管理、服务开发、运维发布、服务运营为一体的一站式开发运营平台,实现了真正意义上的DevOps服务闭环，贯穿了服务交付的CI、CD、CO环节，得益于公司内外部更多优秀组件的集成，包括TKE、蓝盾、QCI、Envoy等。
云原生运维转型思维
这几年运维界听到最多的几句话：“云计算会淘汰掉运维！整个运维行业可能被干掉！再不转换运维就要丢饭碗”，诸如此类。那真相到底是什么？行业有一个共识，即运维工作本身交付的是一种服务，下面举一个可能不太恰当的例子，或者可以帮助大家找到答案。 云计算时代好比组装一辆汽车，根据客户的需要，通过PaaS能力选择匹配的引擎、车轮、离合器、 悬架、车控制系统等进行拼装。客户不用关心汽车各元部件的实现原理，最终获得是一辆满足自身要求的汽车。光有了汽车是玩不转的。还需要有修路、加油站、交通控制等服务体系，运维就是承担这个角色。 相比传统运维，确实是少了自己采购元组与组装的工作。到了后云计算时代（云原生），出现了一个DevOps公司，引入新技术与理念，声称已经将修路、加油站、交通控制等环节都打通了，形成了一体化服务能力，并邀请运维哥一起加入创业。在这个阶段，运维哥出去单干，大概率会翻车。 但加入 DevOps 公司，运维的价值到底还有什么呢？因此，升级与转型是必然的，例如将普通国道升级成高速公路；实现客户在高速路上不停车换轮胎；贴近并理解客户，规划行程中所需的服务来提升客户体验；通过提升智能化水平，连接交通管制，缩短航程，避开损坏路段等等。相信大家心中已经有自己答案了。回到原点的灵魂拷问：“云原生背景下，运维不做转型会不会死？”，“运维要如何快速自救和升级？”。
文化层面
以下几点是我们中心内部实行的几个机制，供作参考，因不同团队间存在一定差异，此处不展开说明。 开发与运维成立FT虚拟团队，实现组织融合； 开发或运维侧的例会、技术分享、事件复盘，FT成员全程参与； 项目立项时，运维接口人需要做“左移”，即提前参与技术架构讨论，有助于运维的问题提前在方案讨论或开发阶段提前暴露，有效做好防范与规避； 建立收集各方反馈问题与建议的机制与渠道，有效将好的想法影响至平台下个版本的迭代中，实现持续改进与优化。
云原生运维目标
在云原生背景下，我们对运维体系进行了升级，在原有基础运维能力之上确定了以下几个目标： 具备服务全链路质量监控覆盖，涵盖数据域与业务域 具备一定智能化的资源动态调度、伸缩机制 具备一定的故障预警、根因分析、问题定位能力 服务具备在交付不同阶段（测试、预发布、运营）抵御异常的能力 具备资源高效交付的流程机制与快速上线的能力 具备多云的资源编排与管理的能力 具备业务快速上云的机制，确保切换过程的高可用性
确定了运维能力升级指导思想：基于运维编排的云原生实例化。广义而言，运维的本质就是多个运营事件的有机串联，来达到质量、效率、成本、安全多维收益，而编排是实现有机串联的有效手段，除了可以沉淀运维经验外，还可以有效实现共享。
CG: 一定要牢记可沉淀、可积累、可共享，形成迭代上升。
CI/CD
平台能力
云端一切皆有操作
- 云资源编排，编排对象是各类云资源，包括公有云、私有云等，采用terraform来实现多云基础设施的编排，可以覆盖腾讯云、阿里云、AWS、私有云等等。
- kubernetes编排，编排对象是k8s集群资源，采用Helm/YAML进行编排。
- 作业编排，编排对象主要是主机节点，对应的操作任务编排，调用现有的蓝鲸job作业平台。 🐋蓝鲸作业平台
运维编排三层之间如何串联？我们采用了开源的蓝鲸标准运维作为编排引擎，将不同的三层编排串联，打破从前跨云、跨平台各种割裂的操作界限，提升运维效率，一切皆编排，并能将编排任务沉淀为能力模板传承交接。
例如上图的场景，我们需要扩容一个现网的TKE业务集群，从基础设施层的资源采买，到容器服务初始化部署，和一些集群特性作业操作等均一站式运维编排完成，操作时长从4小时优化到30分钟内，而且集群再次扩容只需简单修改几个编排参数执行，避免了繁琐重复的操作。在玄图平台能力中将通过自助开发可编排的原子（包括操作、接口、算法等），一切操作皆编排。
云原生监控
云原生业务全链路跟踪（血缘关系链）
混沌工程
Adrian Cockcroft给出了另一个定义则是：混沌工程是一种确保失败所带来的影响能够被减少的实验。
这里我们TKE集群中的服务设计了CPU负载注入演习，启动实验后，CPU按预期提升，当CPU持续高负载时，服务正常且触发自动扩容，无请求超时用户无感知，符合预期，加深了团队对系统可靠性的理解和认知。