基于大规模分布式系统的云原生运维实践
在云计算、大数据、人工智能等新兴技术的推动下,众多行业都在经历一场轰轰烈烈的数字化转型大潮。随着容器技术和编排系统的发展、基础设施不断云化、分布式微服务架构不断演进和敏捷、DevOps等开发理念的带动，应用云化已经是不可逆转的趋势，云原生也成为企业应用现代化数字转型不可不追随的潮流。
随着企业应用逐步向云原生应用进行演进和迁移，具备了更快的迭代速度、更低的开发复杂性和更好的可扩展性，但同时，部署和运维的复杂性和工作量却大大增加。相较于面向操作规则的传统运维，云原生架构下的运维转变为面向可观测数据的自动化、数据化和智能化运维，强调以应用为中心、业务指标可视化和应用全链路分析，面临着新的挑战，如图1所示。
图1 云原生架构下的运维面临的挑战
针对以上的挑战，建议的整体方案如图2所示：参考ITSM、ITIL、DevOps、敏捷、精益等先进方法论作为规划指引，实施云原生相关技术和工具作为支撑，建设突出快的敏态运维转型、突出精的技术运营、突出稳的系统稳定性保障和突出智的DataOps、AIops四大运维能力域作为目标，进而形成包括引入DevOps、基础设施即代码、Docker和K8S、Service mesh、可观测性、DevSecOps和FinOps等关键技术实践。本文主要结合这些关键技术实践如何在云原生运维下更好的落地进行探讨。
图2 云原生运维整体方案
引入DevOps实现持续交付流水线、助力开发运维一体化
DevOps依靠工作流程、人员组织的整合，以协作、自动化、精益、度量、共享、文化为指引，建立一种可以快速交付价值，并且具有持续反馈和改进能力的现代化IT组织。
为了实现稳定、可靠和高效的运维体系，需要有相应的持续集成与交付方式进行配套支撑，在云原生体系下，作为运维团队，通过结合DevOps的方法论、流程、技术和工具，构建一个跨部门协作、质量内建的、持续反馈改进的一体化自动化持续交付流水线很有必要，同时形成标准化的流程和规范，推进应用部署的容器化、K8S化，实现多态研发模式、多分支持续集成、多版本、多环境、多制品库形态、多场景多策略渐进式的自动化发布部署和交付，实现效能提升。
在工具落地上，构建基于Kubernetes/Docker技术和开源工具链的CI/CD流水线，并通过不断的优化和改进，来改善开发人员的体验，使开发人员可以通过自服务的方式更容易的做正确的事情，从而实现服务的快速构建、高效集成和部署交付，同时提升运维团队的敏捷性和效率，加快产品团队的交付速度。
通过基础设施即代码实现多云管理
传统的云平台相关资源和基础设施管理，更多的是偏向运维人员以手动的方式结合云平台的portal和命令行等来进行，会出现重复度高、差异化大、成本高、人为错误等问题。
基础设施即代码，是通过代码而非手动定义的基础设施的供应和管理过程。用代码来描述基础设施的创建、变更、销毁；代码编写好，验证也是正确的，之后每次执行任务都不会出错；非常快速，高效；代码代替文档，有历史记录，可回滚，不用担心文档更新不及时或人员流动带来的“黑盒”问题；不用通过访问生产环境，就能知道生产环境上的配置情况。
作为云原生运维，面临各种不同的公有云/私有云环境和各种跨云/跨平台的操作，迫切需要具备相关工具和开发技能，工具包括Terraform和Packer，其中Terraform是一种开源工具，用可以安全高效地预览、配置和管理云基础架构和资源，Packer是通过模板来定义一些内容然后创建镜像的方式来实现。
在具体实践上，如果是云架构或云资源可以直接通过Terraform结合对应的provider进行操作，并可以根据资源分类创建不同的代码仓库和module；如果是需要定制化的基础组件，可以结合Terraform和Packer实现不可变基础设施，利用Packer去生成定制化的镜像，利用Terraform引用对应的镜像去创建资源，这种方案的好处是一次制作、重复利用，免去每次创建机器、安装服务的重复过程。
Docker和kubernetes解决容器标准化和编排
Docker容器技术的特性使其天然地适用于微服务的落地实现，一个容器实现一个微服务；无论是前端还是后端服务，均建议采用容器化的方式进行编译构建。作为云原生运维，需要结合部署和运行的要求制定dockerfile的规范，并预置统一受管控的支持多种开发语言多版本的基本镜像以备开发使用。
云原生运维更多的是围绕kubernetes的生态，目前很多云平台都具备托管的kubernetes服务，它们具有强化的安全性和快速交付功能，可以通过它们轻松的部署和管理容器化应用程序；对于这种托管的kubernetes服务的运维和保障工作也较为简单，可以结合以上的基础设施即代码进行代码化的管理，同时更多的是持续保障运行在kubernetes里服务的正常、扩容缩容和高可用，并结合业务场景持续提升集群的稳定性和SLA。
对于运维团队而言，Kubernetes这个容器编排的实施标准是成为实现云原生理念的最佳平台，同时可以结合GitOps模型，通过Git服务器和一种特定的工作流模型，为Kubernetes应用提供灵活的自动化部署管理，以实现容器应用的持续交付，以帮助实现容器应用的高可用性、可扩展性和快速响应变更的能力。
基于Service mesh轻量级的微服务治理
微服务模式下，企业内部服务少则几个到几十个，多则上百个，每个服务一般都以集群方式部署，针对服务发现和负载均衡的三种模式：集中式代理、客户端嵌入式代理和折中的主机独立进程代理都分别存在着配置麻烦、治理松散、运维部署复杂等情况。更需要一种轻量化的模式，即Service mesh。
Service mesh是一个基础设施层，是一个服务治理平台，用于处理服务间通讯。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。在微服务体系里面，除了服务本身之外，其它的服务相关的可管理可治理的部分都可以理解为是Service mesh的范畴。
而云原生化，则可以将Service mesh本身的运维与业务容器解耦开来，实现中间件运维能力的下沉，在具体实现上，可根据实际的需求采取不同的技术，比如：基于Consul+Openresty的基础方案方式；或者Istio的方式，Istio是当前最主流的Service mesh开源项目。
对于云原生运维人员，依托于Service mesh打通的服务和基础设施边界，以及对服务的统一抽象，能够更好的从全局视角进行服务质量、依赖管理、容量规划、端到端监控等来保障产品稳定性。
基于云原生的全方位可观测性实现
不同于传统的监控告警机制，在云原生下，可观测性是必备的能力，运维团队需要更全面的考虑基于云原生的可观测性。
云原生可观测性是从传统软件监控及数据分析可视化工具中，总结出在云原生领域中，从底层容器基础设施、通用技术组件到业务应用系统全链路监控运维、运营治理等产品化体系化的能力诉求，确切的体现了云原生的核心理念，它更多的是面向业务，强调将业务全过程透明化的理念。
在具体实现方面，可观测性技术实施具有技术栈多样，场景复杂，数据规模大等特点，作为运维团队，需要通过建立多层次、多维度的可观测特征数据来构建全方位云原生可观测性，并以高度集成的方式反馈这些可观测特征，以创建决策周期，从而提高组织决策的有效性。具体落地方案包括：
① 提供研发使用的基于open tracing 协议的通用统一的日志格式
② 在应用程序级别、基础架构级别和组件级别建立完善的基本监控指标，以及复杂的可靠性和可用性显示
③ 根据实际应用场景，适当的结合云平台提供的相关解决方案
④ 使用商业或开源APM工具实现应用程序的全链路跟踪、故障预警、性能定位、根因分析和优化
⑤ 使用Elasticsearch、Kibana、Grafana、Prometheus、Loki、Thanos和其他工具，将不同来源的数据以单一和连贯的方式进行呈现
持续优化DevSecOps和FinOps
云原生安全作为一种新兴的安全理念，不仅解决云计算普及带来的安全问题，更强调以原生的思维构建云上安全建设、部署与应用，推动安全与云计算深度融合。
作为运维团队，对安全需要特别重视，需要规划安全架构、评估风险态势、建设安全开发体系、防护加固体系和运维应急体系。在具体实践方面，可以基于风险评估模型建立环境和数据安全以及合规管理，比如每年合作并支持信息安全级别保护和各种安全行动，以实现系统级安全；支持和配合相关部门要求的其他防护活动，并参与攻防演练；加强安全管理机制，丰富安全审计战略；防火墙加固、策略调整和优化、实时防御安全攻击；定期修补、漏洞扫描和组件更新。
在云成本优化方面，参考FinOps能力模型，通过多种措施持续优化云成本，以降低使用云平台的费用。比如：持续分析账单以实现成本控制；通过对公有云产品特性的认知和理解，不断调整和优化；为不同环境设定产品标准，以实现精细化管理；跟踪资源的生命周期，尽可能减少浪费。
结束语
除上述外，还有运行时管理、混沌工程等技术实践，同时还需要有运维团队日常管理、和外部协作沟通模式、变更审批、可视化、汇报机制、知识库、培训体系、7*24 on call等文化、组织、流程和管理等方面的全方位支持。
云原生下，运维团队的挑战较大，任重而道远，需要尽快实现标准化、自动化和数智化，其中标准化可以促进开发和运维的沟通和协同、有助于生态分工、推动更多工具链的高度集成；自动化可以支撑更大规模业务的挑战、能够持续支撑业务的快速迭代与稳定性；数智化可以通过对监控、配置、性能、日志等运行数据进行加工计算、构建可量化可对比的技术运营指标数字化评价体系并逐步形成结合业务场景的可落地的AIOps能力。