运维工作思考

发表于 | 分类于

前言

  这两年随着公司在各行业领域的深入以及运营策略的调整，平台业务量有了突飞猛进的增长。在实际运维过程中，因为业务系统越来越复杂，变更越来越频繁，总是存在各种各样监控未覆盖或者以前未知的故障发生，服务器也是处理野蛮增长的状态，然而运维还停留在“刀耕火种”的原始状态。
  在这种工作方式下，服务器的安装、初始化，软件部署、服务发布和监控都是通过手动方式来完成的，需要运维人员登录到服务器上，一台一台去管理和维护。这种非并发的线性工作方式是制约效率的最大障碍。同时，因为手动的操作方式过于依赖运维人员的执行顺序和操作步骤，稍有不慎即可能导致服务器配置不一致，对于数据库或MQ的误操作甚至会带来灾难性的故障，即便现在用了docker，也写了一些自动化的脚本提升工作效率和质量，但充其量也只是个“石器时代”的DevOps。

解决方向

  现阶段，无论项目层面还是运维层面，都有三个大方向的问题需要解决：

  • 质量
    运维完成质量体现在可用性(是否稳定、用户体验是否友好）、规范性、安全性(除了防范攻击以外，还包括应急容灾等），其中，对于一个已上线的商用平台稳定性尤其重要，稳定是1，其他都是0。
  • 效率
    由于运维人员和其他职能线条的人员比例不匹配，对于基础设施的交付、中间件的交付，代码发布、故障的处理、定制化项目的交付等，如何使这些任务完成更高效，这是运维人员面临的主要问题。
  • 成本
    在项目上运维部门往往被定位为消耗部门，实际交付过程中运维费用往往包含在开发费用里，如何通过最少的人力完成SLA是运维部门帮项目赚钱的唯一方法。另外，项目越大往往服务器等成本支出就越大，然而这个增长比例不一定是正确的，所以运维成本最核心要解决的是搞清楚具体钱花在哪个方向，并对这些成本问题进行优化。

解决方案

技术层面解决

  合理利用CMDB、监控、流程、自动化工具和日志分析工具解决质量、效率、成本问题。

  1. 质量层面
    1.1 梳理系统短板，加强处理。通过CMDB(配置管理数据库)，梳理服务间的依赖关系，找出强依赖核心模块，排查单点模块，梳理参数配置的合理性，重点保障和优化。例如mysql、mongo、redis、rabbitmq等。
    1.2 对现有监控进行查漏补缺。主要体现在：

    • 现有监控系统的覆盖范围，核心业务模块、主机、中间件、数据库等是否有覆盖。
    • 监控方法的有效性，是否包含了核心指标的监控，是否有利于故障排查和日常分析，能否会对生产系统无感知监控。
    • 告警策略的合理性和有效性，包括告警渠道的使用是否合理、告警内容是否清晰、升级机制是否合理、避免短信轰炸等。

    1.3 通过流程提高运维质量。虽然现在都在提倡DevOps，但必要的流程是质量把控的主要手段，能让大家知道什么时候做什么、怎么做。(参考ITIL管理机制)

    • 故障处理流程：重点确定故障处理时的熔断机制。
    • 变更发布流程：重点评估影响范围、操作顺序、回退机制涉及的数据和配置以及发布的时间窗口。评审的依据应以CMDB配置管理为基础，基于业务流程和边界服务一起评估。
    • 事件处理流程：由于一般的中小型公司运维人员严重不足，也没有业务方向的客服人员，所以在事件处理流程的基础上，应重点设计事件和服务请求的定义，处理的时间窗口、事件的升级机制等。

    1.4 应急容灾系统的建设
    很多公司不一定有条件做灾备系统，这和成本、技术架构、服务级别都有关系，但在系统部署和架构设计时应考虑扩容和容灾能力，底层数据库、中间件应做好备份，部份服务可考虑提前做好异地多活，以便故障发生时可在其他快速复制一套环境提供服务。
    1.5 自动化运维工具的落地
     $emsp;重要性无需质疑，除了运维批处理操作以外，还需要考虑自动化测试工具，以及故障时的常规操作脚本，避免误操作带来的二次故障。

  2. 效率层面
    2.1 合理利用云上产品。由于人员不足以及能力上的欠缺，合理利用云上服务能大大降低运维成本，让云维人员把精力更多的放在运维工作上。
    2.2 运维工具的使用。市面上已有很多成熟的运维工具可以使用，如zabbix、ELK、Ansible、Saltstack等等，运维人员无需重复去制造轮子，应把精力花在如何用好工具，而不是增加多一套维护成本。与此同时，对于流程上确定的一些故障处理办法、版本发布方法，备份管理办法等，运维人员可优先开发相关脚本或工具，在提高操作效率的同时，也降低了学习成本和操作风险。
    2.3 让系统助自一定自愈能力。为解决人力问题，运维除了在日常的操作上让系统具备自动化能力，同时，可重点对于故障处理里程里定义的重启、failover、空间清理等标准操作做成自动化，当监控触发告警时，让系统具备一定的自我恢复能力，从而减少故障影响时长。
  3. 成本层面
    3.1 分析服务器费用占比，分析成本的合理性。
    3.2 通过CMDB和监控平台分析主机的性能情况和应用部署的合理性，对于不合理的部署项目上进行优化。
    3.3 完善业务日志，对每笔业务形成链路追踪，分析每笔业务的费用占比，对费用占比大但使用率少的业务模块进行部署调整，或从产品层面对功能进行优化，甚至关闭。

管理层面解决

  大部份公司都在推行DevOps的模式，但是核心理念并不在于让开发处理运维的工作，所以运维团队更多的职责是为开发团队提供运维的能力，与此同时，运维人员需在文档、工具层面做出更多的沉淀，尽可能弱化人的重要性。
  运维团队的管理主要体现在以下几点：

  1. 责任到人。可按业务维度分配到个人，对于核心的业务模块和业务流程所有人必须共同承担。
  2. 每个人必须掌握业务领域中用到的服务、数据库、中间件等维护技能，对公共的基础服务每个人都需掌握基本的维护技能。
  3. 每个人每个月必须对自己负责的业务模块和基础服务提出问题并优化，如需开发人员或产品人员解决的问题需跟进处理进度,优先从事件工单提取最常见问题加以优化。
  4. 每个每个月需完成一篇知识库，并评审通过。
  5. 采取轮岗机制，每个人需要对其他人负责的业务模块加以学习，并通过考核。