单应用的交付完成之后 ， 其实是更多的不是项目维度 ， 项目维度我们可以组织让业务线去做人工地编排 ， 编排应用之间流水线以及它的一些前置依赖 。

文章图片

在一般情况下交付到了发布就完成 ， 其实我们在发布完成之后还可以做一些服务治理健康保障 ， 例如我们有触发的压测 ， 以及强弱依赖等 。
这就是我们具体的实践 。 我再总结一下 ， 具体实践第一是规范化 ， 保证我们整个流程的顺畅与自动化 。 第二是多种手段保证质量 ， 质量门禁保证问题的蔓延 。 第三是拆分应用画像 ， 使画像确定我们的运维最小单元 ， 实现可发布可运维 。 第四是通过流水线使我们整个流程更顺畅 。
三、未来规划
最后再来看一下我们近期的一些规划 。
1、开发平台
第一部分是开发平台 。 在整个开发活动过程中 ， 所占比例最大的还是写代码 ， 我们怎么能让写代码效率更高 ， 所以我们计划做一个开发平台 ， 其实也是一个开发插件 。 这个插件主要有哪些功能呢？
它可以接口调用自动生成 ， 我们会有原数据信息中心 ， 去采集我们现在整个公司提供的接口信息 ， 然后业务在开发代码的时候就可以自动拿到这些依赖 ， 然后自动地生成代码 。
生成代码的同时 ， 它还可以进行一些服务治理的配置 ， 后续我们希望联动其他的工具 ， 例如我们联动qconfig(配置中心)配置自动生成以及联动我们的服务治理 ， 然后自动生效等 。
开发平台 ， 极大地提升我们的开发效率 。 开发平台最终要达到的效果就是让我们代码编写更简单 ， 规范落地有载体 ， 服务治理更有效 。
2、混沌工程
第二部分混沌工程 ， 《又一宕机事故！都怪当初没做好故障演练系统……》有详细的介绍 。
3、服务可观测平台
第三部分是服务可观测平台 ， 刚才我们说了基于应用画像让我们应用做到可观测 ， 可发布 ， 可运维 ， 但是其实对于它整体的状态 ， 我们还需要有一个可观测平台 。 基于云原生的思想 ， 让我们的应用服务可观测 ， 它主要分为三个领域的实践 。

• 系统技术先进性 ， 系统当前使用的是不是TC组件 ， TC组件是不是最新的 ， TC组件它其实是所有服务的一个基石 ， 后续的Trace链路 ， 各种的治理全都依赖于它 。 技术先进性可观测之后 ， 尤其是团队维度 ， 在整个公司技术演进的时候 ， 我就可以先着力地去改进它 ， 去发力去做一些感性的应用 。
• 健康度 ， 系统健康度是指我当前的系统是不是有报警 ， 它是不是多机房灾备 ， 质量保障手段是不是足够健全等 ， 我可以据此了解应用的健康度 。
• 一旦遇到了问题 ， 我们可以快速定位 ， 像上述我们说的日志、Trace以及监控等 。

已上是分享的全部内容 ， 大家如果有什么想法 ， 欢迎在评论区提出~
>>>>
Q&A
Q1:在CI/CD流水线执行通过后才可以进行test测试流水线执行 。 怎样控制两个流水线的执行顺序？建立两者的关联?
A1：我有三点建议 。 第一是流水线的出发尽可能的做到自动化 ， 自动化的话就相当于避免人工的处罚 ， 这样你的顺序基本上就可控了；第二是设置卡点 ， 流水线需要有一些前置的卡点 ， 就是达到什么标准 ， 然后才能去执行这条流水线 ， 这样就解决了这一问题 ， CI/CD不通过是不允许执行测试流水线的；第三是在一个项目阶段 ， 流水线其实是对同一个应用来说 ， 或者是同一个应用同一次提交来说 ， 它其实不是说同一次提交 。 同一个应用来说的话 ， 流水线是区分开发 ， 测试 ， 集成 ， 最终到线上的 ， 所以我们可以确定一个唯一的标识 ， 然后每一个流水线里边都会有一个唯一标识 ， 可以把这个过程给串联起来 。