对于许多金融企业来说，都有一套完善的 IT 体系。这是资产，但也可能成为一种负担。业务发展要求我们更加快速的交付，打通开发和运维的壁垒是必由之路，然而，越是有着完善 IT 体系的组织，越是难以打破这个壁垒。自上而下的变革是有必要的，但对于开发和运维部门来说，必须要有自己的发展思路。

在一个云原生正常运作的组织中，开发和运维的职责有着一定程度的偏移。运维部门的人可能会走向两个截然相反的方向。

一部分人会倒向基础设施，为组织提供 PAAS 平台服务。Kubernetes 无疑是这个平台的基础。但顾名思义，PAAS 平台需要为其他人提供一个可以直接部署应用的平台。对这个平台的用户来说，他可以只提供一个应用，提出对资源的需求，然后就可以得到一个运行的应用，这个过程无需人工干预，这就是一个称职的平台了。

这个平台要具备与开发衔接的能力。CI/CD 工具肩负了这个责任，因为开发和测试都使用 CI/CD ，似乎双方共同承担。其实不然，因为许多组织的应用可能来自不同的独立开发团队，甚至有一些可能是外采的，所以由更加统一的运维团队承担这个职责更加合适。可以制定共同的标准，规范各个研发团队。CI/CD 本身是一个涉及多个部门协作的平台，不仅仅需要与开发配合，也可能需要支持来自质量保证的需求，所以这个平台的构建者需要综合的能力。不仅仅需要深入理解开发者的需求，也对研发流程有着深入的认识。

当然这个 PAAS 不是来者不拒，而是需要制定标准。如前文所述，运维团队，以及运维团队管理的对象更加集中，更适合建立标准。kubernetes 为运维中的主要元素建立了标准，通过这些标准元素，可以实现大多数的应用运维需求。为了某一些不符合云原生最佳实践的需求调整，会给运维团队带来巨大的成本，所以运维团队应该建立自己的标准，管控研发团队。因为 kubernetes 本身就是高度自动化的平台，所以管控大多也可以通过技术手段自动实现。

PAAS 的能力也很重要。Kubernetes 已经广泛运用到了无状态服务的管理，但是对于数据库等有状态服务的管理，应用还不算太多，但是需求逐渐多了起来。随着业务的发展，分布式数据库成为了一个必然的选择。分布式数据库分布在许多节点上，为了方便管理，许多先发厂商为自己的分布式数据库产品配套了复杂的集群管理软件。这些软件往往使用自己的管理模型，与组织现有的运维自动化和监控系统融合，需要额外的工作量。所以，运用 kubernetes 的能力，实现云原生的分布式数据库是一个更好的选择。但是这个选择还有许多相关的技术还没有大规模的运用，但是已经有许多有参考价值的尝试。

PAAS 能力的另一个方面是可观测性的提升。Kubernetes 有一系列的云原生组件，可以共同组建一套包含日志、健康状态、metrics 和 trace 的可观测性服务。早期的 Trace 功能，多是通过代码中埋点实现，如果是不可控的应用供应商，则可能无法配合实现。在 Kubernetes 层面，可以通过 Service Mesh 实现 trace 功能。因为是通过基础设施配置实现，也更加灵活。

运维的另一部分人会向业务靠拢。这些人需要了解业务，清楚业务中最关键的监控指标；同时也熟悉 PAAS 平台的能力，能够根据需求，运用 PAAS 平台的能力，实现业务层面的运维管理。

• 建设 PAAS 平台
  • 衔接开发与运维 CI/CD 建设
  • 通过技术手段实现自动化管控
  • 提供灵活的云原生数据库服务
  • 提高应用的可观测性
• 建设 SRE 团队