自动化运维项目总结计划报告总结计划.docxVIP

.. . . .. 自动化运维系统研发项目 总结报告 一、 项目背景 随着信息时代的持续发展 ，IT 运维已经成为 IT 服务内涵中重要的组成部分 。 面对越来越多复杂的业务 、多样化的用户需求 ，不断扩展的 IT 应用需要越来越合理的模式来保障 IT 服务能灵活便捷 、安全稳定地持续保障 ，从初期的几台服务器发展到庞大的数据中心 ，单靠人工已无法满足在技术 、业务、管理等方面的需求 ，那么标准化、自动化、架构优化 、过程优化等降低 IT 服务成本的因素越来越被广大行业客户重视 。 二、 自动化运维研发阶段性 经过对市场背景的分析 ，在公司高层资源的支持下 ，2016 年 7 月完成项目立项及成立研发项目团队 ，12 月已完成初步框架认定工作，在对市场需求 、业务环境调研过程中 ，认为自动化运维需满足 架构独立 、部署友好 、可运维性 、容错容灾 、质量监控 、性能成本 、用户体验等特点 。 项目组经过半年的研发努力 ，项目研发有了阶段性的突破成果 。 2.1 架构独立 任何架构的产生都是为了满足特定的业务诉求 ，如果我们在满 . 专业 word 可编辑 . .. . . .. 足业务需求的同时 ，能够兼顾运维对架构管理的非功能性要求 。那 么我们有理由认为这样的架构是对运维友好的 。站在运维的角度 ，所诉求的架构独立包含四个方面 ：独立部署 、独立测试 、组件规范 、技术解耦等 。 2.2 部署友好 希望从端到端打通开发 、测试、运维的所有技术环节 ，以实现快速部署和交付价值的目标 。实现高效可靠的部署能力 ，要做好全局规划 ，要保证部署以及运营阶段的全方位运维掌控 ，从以上要求分析，有五个维度是对部署友好相关的 ：CMDB 配置、环境配置 、依赖管理 、部署方式 、发布自测等 。 2.3 可运维性 运维从脑海中是最理想的服务架构 ，首先想到的事可运维性强 的那种类型 。 不具可运维的应用或架构 ，对运维团队带来的不仅仅 是难题 ，还有阻止运维人员职业发展前进堵绊脚石 ，因为维护一个 没有可运维性的架构 ，简直就是在浪费运维人员的时间 。因为可运 维性按操作和管理规范应归纳为以下几点 ：配置管理 、版本管理 、 标准操作 、进程管理 、空间管理 、日志管理 、集中管控等 。 2.4 容错容灾 运维的四大职责 ：质量、效率、成本、安全。安全是一个运维 . 专业 word 可编辑 . .. . . .. 团队首要保障的 ，运维人员立项的高可用架构设计应该包含以下几点：负载均衡 、可调度性 、本地双活、主从切换 、柔性扩展等 。 2.5 质量监控 保证和提高业务质量是自动化运维研发的目标 ，而监控能力是我们实现目标的重要技术手段 。为质量监控提供便利和数据支持 ，需实现以下几点 ：指标度量 、基础监控 、组件监控 、业务监控 、链路监控、质量评估、数据库监控等 ； 2.6 性能成本 成本问题 ，也就是技术 ROI（投入产出比 ）的问题 。当系统规模和体量变大之后 ，掌控在运维手中的各类资源 ，将占整个研发团队支出的大头 。如果没有很好的成本控制意识和策略 ，资源体量将会持续增大 ，甚至是翻倍或指数级的增长 ，对于公司成本会是非常大的负担和压力 。 运维工作者需要考虑到服务器 CPU 资源利用率的提升 （引申出来各种虚拟化 、容器或云资源的使用 ）、 IDCCDN 流量带宽使用的管控 ，还有人力的投入和成本的管控 。 如何使得系统能够更高效地被充分利用起来 ，如何能够最大限度的减少成本支出 ，是我们必须要去考虑的问题 。 . 专业 word 可编辑 . .. . . .. 2.7 用户体验 这里提到的体验 ，指的是终端用户的访问体验 。对于非功能或非产品的使用体验 ，运维最需要关注的是访问速度 。开发团队可能 更多的注意力会放在自己负责的代码以及该部分的性能问题 ，不会关注到端到端全流程的性能和体验 。而运维可以站在全局的角度来审视和治理整个端到端的全链路性能情况 ，并给出对应的性能优化建议 三、 项目总结 3.1 项目研发经费 3.2 研发工作总结 在研发运维自动化项目 ，遇到了很多问题和经验 ，要实现运维价值最大化 ，就要确保业务质量 、效率、成本的全面提高 ，业务架构是不得不面临的问题 ，能站在不同角度对业务架构提出建议和需求，才能持续优化出最好的架构 ，在研发过程中一定要着重注意以下两点： 一定要标准先行 ，做到技术的标准化 。这包括资源标准化 、 OS 的 基础配置标准化 、基础软件 （如 Tomcat 、JVM）配置标准化 、应用配置标准化 、流程规范标准化等等 。做到了标准化 ，消除了各种差 . 专业 word 可编辑 . .. . . .. 异，才能为后续的自动化开发铺平道路 。 在技术建设上