要素3：配置（Config）——在环境中存储配置 。
要素4：后端服务（Backing Services）——把后端服务当作附加资源 。
要素5：构建、发布、运行（Build、Release、Run）——严格分离构建、发布、运行 。
要素6：进程（Processes）——以一个或多个无状态进程运行应用 。
要素7：端口绑定（Port Binding）——通过端口绑定提供服务 。
要素8：并发（Concurrency）——通过进程模型进行扩展 。
要素9：易处理（Disposability）——快速启动和优雅终止可最大化健壮性 。
要素10：开发环境与线上环境等价（Dev and Prod Parity）——尽可能保持开发、预发布、线上环境相同 。
要素11：日志（Logs）——将日志当作事件流 。
要素12：管理进程（Admin Processes）——将后台管理任务作为一次性进程运行 。
要素13：优先考虑API设计（API First） 。
要素14：通过遥测感知系统状态（Telemetry） 。
要素15：认证和授权（Authentication and Authorization）
另外 ， 今年年初 ， 信通院牵头进行了云原生成熟度标准体系的讨论和标准制定 ， 在这个体系里面包括一个云原生业务应用成熟度的评估标准 ， 根据基础设施域、应用研发域、服务治理域以及组织管理域成熟度综合计算 ， 共分为五级 ， 五个级别有明确的定义 ， 比如在初始级 ， 技术架构局部范围开始尝试云原生化改造 ， 并取得初步效果 ， 而卓越级 ， 技术架构已完成全面云原生化改造 ， 且这个技术模块功能已相当完善 ， 能够很好地支撑上层应用 。 目前这个标准的细则还在酝酿中 。
中小银行也需要百人规模的技术团队吗？ 首先 ， 我们从什么是云原生架构的角度来理解技术团队职责划分 ， 再去决定技术团队规模会容易一些 。 简单来说就是把原来开发部门需要开发业务功能的工作下沉到基础设施 ， 把运维部门对于基础设施（例如云计算）的一些原生能力赋能上层业务应用 ， 所以在云原生架构之下 ， 原来开发部门和运维部门的工作职责就出现了冲突 ， 那么中小银行如何在人力、资金、资源相对紧缺的情况下 ， 有效规避这些冲突 ， 目前在金融行业普遍的做法有以下三种：
第一种做法：可以考虑专门成立一个容器管理部门 ， 这个部门介于开发部门和运维部门之间 ， 这个部门不用关心基础设施硬件的建设 ， 它不仅是容器平台建设的计算、存储、网络资源的使用者 ， 同时它也是支撑业务应用开发的开发环境、开发工具、容器应用日志监控等能力支持的提供者 。
第二种做法：从现有开发部门或者运维部门拆分成一个虚拟团队 ， 这个虚拟团队可以专门负责容器平台的日常运维管理事宜 ， 一般建议从运维部门拆分出一个这样的虚拟团队 ， 这样可以提升容器平台日常运维管理的沟通和协调效率 。
第三种做法：通过引入针对各个部门不同使用场景的多视图和权限的云原生平台来细化工作职责的划分也是一个不错的选择 ， 国内灵雀云等厂商都有类似成熟的云原生平台使用案例 。
飞快的技术更迭下 ， 中小银行如何稳健选型 相较于大型股份制银行 ， 中小银行可能面临着IT人员相对匮乏、技术能力相对薄弱、IT系统至今沿用传统架构等问题 ， 那么在实施云原生架构改造过程中应如何进行选型 ， 如何分批次将现有架构纳入改造 ， 传统核心类应用是否适合进行容器化改造 ， 也是现阶段中小银行重点关注的问题 。
针对这些问题 ， 灵雀云首席架构师杜东明表示 ， 中小城商行在容器化选型时 ， 应该尽量选择具备丰富落地及咨询经验的企业和成熟的产品 ， 实施步骤上建议初期以容器基础设施建设结合DevOps工具链建设 ， 让中小城商行能快速享受云原生带来的收益 。 同时选择在容器及基础设施、微服务、DevOps三大领域都具备支持能力的产品和公司 ， 能够有效减少后期由于兼容性问题带来的运维成本 ， 这一点对于技术人员相对较少的中小城商行尤为重要 。