MadBOK

# 解决方案架构的运维设计

每一个新项目在期初都需要大量的资源和仔细的规划，我们可能会花很长时间来创建和发布应用程序，产品发布后，我们还需要让应用程序持续保持运行，持续监控应用程序，以及时发现并解决出现的问题。运维团队需要处理好应用程序的基础设施，安全性和任何软件方面的问题，以确保程序能够可靠运行。

架构的各个组件和各层都应该考虑高效的运维，现代微服务应用程序涉及到太多组件，使得运维成为一项复杂的任务，运维团队需要建立适当的监控和告警机制来解决出现的问题。

# 解决方案架构运维的原则

高效的运维是指在应用程序运行时尽可能减少中断，从而获得最大的业务价值，他旨在通过持续改进来使系统高效运行，下述设计原则可以参考：

  • 自动化运维。可以将手动工作自动化，使用自动化的手段来主动发现和响应安全威胁，对于面向web的应用程序，可以使用机器学习在异常影响系统之前提前检测，安全问题自动上报，也可以将基础设施自动化，并作为一键式解决方案进行多次重新部署。自动化有助于避免人为错误，是IT运维必备的利器。
  • 进行增量和可逆变更。运维优化是一个持续的过程，工作负载设计时应允许所有系统组件进行定期更新，通过频繁应用小步变更来避免同时进行多个变更所导致的重大影响。任何变更都应该是可逆的，以便在出现问题时系统能恢复正常工作状态。增量变更有助于进行全面测试，并提高系统的可靠性。
  • 预测并响应故障。故障必然会发生，尽可能提前识别故障尤为关键，在架构设计过程中，要对故障进行预测，确保进行容错设计。应假设一切都可能在任何时候出现故障，并为之做好备份计划，定期进行预演，找出潜在故障原因，根据SLA来创建测试场景，确保能理解测试的结果，并有效的解决问题。
  • 从错误中学习并改进。系统发生故障时，应该从错误中吸取教训，找出问题所在，确保同样的问题不会再次发生，改进的方法是进行根因分析（Root Cause Analysis，RCA）。
  • 持续更新运维手册。运维手册应该包括定义好的RTO/RPO、延迟和性能等方面的SLA，管理人员应该在运维手册中维护启动、停止、打补丁和更新系统的步骤，记录所有以前事件和团队成员为解决这些问题所采取的行动，这样有利于在快速解决类似事件时做标准参考，可以通过脚本自动化运维手册，系统变更或每次构建以后，为文档自动添加注解。

# 解决方案架构运维的技术选型

# 规划阶段

运维流程的第一步是定义运维优先级，以专注高度影响业务的领域。在理解优先级后，需要对运维工作进行设计，这需要充分了解工作负载，以设计和构建足以支撑他们的流程。工作负载的设计应该包括如何实施、部署、更新和运维。整个工作负载可以看作由各种应用程序组件、基础设施组件、安全、数据治理和自动化运维共同组成。

设计运维时，可以参考以下实践：

  • 使用脚本自动化运维手册，以减少人为错误。
  • 根据定义好的标准（环境、版本、应用程序所有者、角色），使用资源标识机制来执行各种操作。
  • 将事件响应流程自动化，以便在发生故障的情况下，系统不需要太多人为干预即可开始自我修复。
  • 使用工具来自动管理服务器实例和整个系统。
  • 在实例上创建引导脚本，以便在服务器启动时自动安装必须的软件和安全补丁。

完成运维的设计后，要建立一套检查清单，用于检查运维工作是否都已就绪，这些检查清单应该确保上线后即可提供良好的运维支持，其中包括日志和监控、沟通计划、告警机制、团队技能、团队支持、供应商支持等等。

运维的规划需要跟踪IT库存资产的使用，这些资产包括基础设施硬件，如服务器、网络设备、存储设备、终端用户设备等等，此外还需要跟踪软件许可证、运营数据、法律合同、合规要求等。企业的IT资产包括企业执行业务活动所需的任何系统、硬件或相关信息。

IT资产管理包括如下几个阶段：

  • 规划：资产生命周期始于规划，其确定对整个T资产的需求和采购方法。它包括成本效益分析和总体成本评估。
  • 采购：在采购阶段，组织会根据规划来采购资产，也可能决定根据需要开发一些自有的资产，例如，用于日志记录和监控的内部软件。
  • 集成：在集成阶段，资产会被安装在环境中。集成工作包括对资产的运维和相关支持，以及对用户访问权限的定义，例如，安装日志代理以从所有服务器收集日志并将其展示在集中式的仪表盘上，将监控仪表盘指标的权限只开放给运维团队。
  • 维护：在维护阶段，运维团队会跟踪资产，并根据资产的生命周期进行升级或迁移，例如，应用软件供应商提供的安全补丁。另一个示例是跟踪许可软件的使用寿命，例如，随着旧操作系统的使用寿命到期，将Windows 2008迁移到Windows 2016。
  • 停用：在停用阶段，运维团队将处置报废资产。例如，如果旧数据库服务器的使用寿命即将到期，团队将对其进行升级，并将所需的用和支持迁移到新服务器。

配置管理是资产管理的一部分，它存储资产的配置记录，并着眼于资产管理的集成和维护部分。

配置管理会处理资产管理的部署、安装和支持环境，配置管理工具可以提供随时可用的资产配置信息，帮助运维团队减少停机时间。

# 执行阶段

运维的关键在于主动监控和快速响应，这样在发生故障时系统才能快速恢复，可以通过了解工作负载的运行健康状况来识别故障何时发生以及响应措施何时生效，可以借助一些具备度量和仪表板功能的工具来了解工作负载的健康状态，同时将日志数据集中存储，并定义指标以建立基准。通过定义和了解工作负载的内容，可以对运维问题进行快速而准确的响应。

跟踪系统健康状况对于了解工作负载行为至关重要，监控需要应用到架构的每一层，以下是需要监控的重要组件：

基础设施监控指标：

  • CPU利用率：服务器在给定时间内所使用的CPU百分比。
  • 内存利用率：服务器在给定时间内所使用的内存百分比。
  • 网络利用率：网络数据包在给定时间内的入站/出站情况。
  • 磁盘利用率：磁盘读写吞吐量和每秒输入输出量。
  • 负载均衡器：给定时间内的请求次数。

有时基础设施都是正常的，但是应用程序可能会由于代码错误或缺陷而出现问题，应用程序监控包含如下指标：

  • 端点：给定时间段内的请求次数。
  • 响应时间：完成请求的平均响应时间。
  • 节流：系统容量超限时能处理的有效请求数。
  • 错误：应用程序在响应程序时抛出的错误。

安全对于应用程序也至关重要，如下是安全方面需要监控的地方：

  • 网络安全：监控未经授权的端口开放、可疑的IP地址和活动。
  • 用户访问：监控未经授权的用户访问和可疑的用户活动。
  • 应用程序安全：监控恶意软件或病毒攻击。
  • Web安全：监控DDoS攻击、SQL 注入或跨网站脚本（XSS）。
  • 服务器安全：监控安全补丁的漏洞。
  • 合规性：监控合规性漏洞。
  • 数据安全：监控未经授权的数据访问、数据脱敏和数据在静止和传输中的加密。

设置监控时，可以定义系统阈值以及在何时需要发出告警，例如服务器CPU利用率达到了70%，并且持续了5分钟，监控工具就应该记录下服务器的CPU利用率，并向运维团队发送告警，让运维团队在系统崩溃前采取行动，将CPU利用率降下来。

通常情况下，需要定义告警级别，运维团队会根据告警的严重程度来准备响应的举措，如下是一个告警优先级的示例：

  • 严重级别1(Sev1)： Sev1的告警最严重，需要优先解决。Sev1问题只应当客户受到重大影响，需要立即进行人工干预时，才会发出告警。Sev1告警可能是整个应用系统瘫痪。团队需要在15分钟内对这类告警做出响应，并且需要全天候的支持来解決问题。
  • 严重级别2（Sev2）：Sev2是高优先级的告警，可以在工作时间处理。例如，应用程序已经启动，但针对特定产品类别的评分和评论系统无法工作。困队需要在24小时内响应这类告警，在正常的工作时间提供支特来解决这个问题。
  • 严重级别3（ Sev3）： Sev3是中等优先级的告警，可以在几天内的工作时间来处理，例如，服务器磁盘的空间将在2天内占满。团队需要在72小时内响应这类告警，在正常的工作时间提供支持来解决问题。
  • 严重级别4 (Sev4）：Sev4是低优先级的告警，可以在一周内的工作时间处理，例如，安全套接层（SSL） 证书将在2周内到期。因队需要在一周内响应这类告警，并且只需要在正常的工作时间提供支持来解决问题。
  • 严重级别5 (Sev5）：Sev5属于通知，不需要上报，例如发送部署完成的通知，所以可能并不需要响应。

# 改进阶段

运维需要持续改进，才能随着时间推移而趋于完备，为了改进运维，分析所有运维事件和活动是必要的，分析故障有助于预测未来的事件，并且使团队做好准备。应实现一种机制来收集运维事件、跨工作负载的各种活动和基础设施变更的日志，并维护和跟踪好活动信息和记录，以便审计。

数据收集到集中存储系统后，就可以进行转换，以便于搜索和分析。可以使用Spark、MapReduce、AWS Glue等大数据应用来实现数据的转换和清洗。为了实现数据的可视化，可以使用一些B工具，如Tableau、MicroStrategy、Amazon QuickSight等。

# 利用云服务来实现运维

规划阶段包括识别不足之处和提出相应建议，通过脚本进行自动化以及管理服务器机群的更新和补丁安装。具体步骤如下：

  • AWS Trusted Advisor根据预设的最佳实践来检查工作负载，并提供实油建议。
  • 使用AWS CloudFormation可以将整个工作负载视为代码来进行管理，包括应用程序、基础设施、策略、治理和运维。
  • AWS Systems Manager提供了对云服务器进行批量打补丁、更新和整体维护的能力。

执行阶段是指实施运维最佳实践和自动化功能后，需要对系统进行持续监控，以便能够及时对事件进行响应。有如下服务可以使用：

  • Amazon CloudWatch 提供了数百个内置指标来监控工作负载的操作并根据定义的阈值触发告警。它提供了一个集中式日志管理系统并能够触发事件的自动响应功能。
  • AWS Lambda可用于自动响应运维事件。

改进阶段意味着当系统出现故障后，需要确定它们的模式和根本原因，以便持续改进。应该遵循最佳实践来维护运维脚本的版本。以下服务可以帮助识别系统不足并进行改进：

  • 使用Elasticsearch来分析日志数据，以深入了解问题，并尝试通过分析从经验中学习。
  • 利用AWS CodeCommit将库、脚本和文档以代码的形式维护在中央仓库中，以便共享和学习。

← 解决方案架构的成本设计 →