优维科技CEO王津银 - 应用，运维管理的核心维度

2020-02-27 58浏览

  • 1.应用，运维管理的新思维 嘉宾：王津银，优维科技CEO
  • 2.About Me • 05到07年参与电信BOSS系统研发，承担了其中资源管理模块（模块化架构）。 • 07年进入腾讯，接手ISD所有应用发布，并构建了ARS系统。 • 08年，接手自动化构建，其中主导从CC到SVN环境的迁移，重构了其中部分脚 本。 • 12年之后，主导YY和UC的运维平台体系构建，在阿里UC顺便把游戏的微服务 化改造做了。 • 15年创业，全栈运维平台EasyOps，DevOps管理专家。
  • 3.• 运维的困境及突破 • 应用的资源管理视角 • 应用的动作管理视角 • 应用的状态管理视角 • 应用的平台管理视角
  • 4.从IT模式看运维 • IT模式以瀑布流和敏捷驱动研发模式为主,部门墙 • 运维一直被孤立，从未被重视
  • 5.以下问题是如何思考的  如何看待如下问题  ITSM，IT和业务的距离真的近了么？  IT真的做到敏捷了么？  CMDB为什么鲜有成功案例？  为什么才意识到IT自动化的价值？
  • 6.Dev和Ops冲突之源 • 研发只关心产品需求 • 非功能需求就交给运维
  • 7.持续交付的核心是应用管理 应用的状态=资源的状态 CMDB IT资源管理系统 应用的变更=资源的变更 资 源 动作 持续交付， 作业变更 持续部署 运维变更 状态 智能监控 数据分析ITOA 应用 • CMDB系统要实现向资源管理系统的过度。 • 应用的变更场景最终是对资源的变更。 • 应用的状态最终是由其资源的状态来决定的。
  • 8.• 运维面临的问题及解决方案 • 应用的资源管理视角 • 应用的动作管理视角 • 应用的状态管理视角 • 应用的平台管理视角
  • 9.人工 维护 数据入库 数据入库 人工 维护 应用管理之资源管理 应用层 基础资源层 自动 发现 • CMDB架构分基础资源层架构和应用 资源层架构 数据入库 • 应用层资源架构把相关的资源以应 用为中心实现资源整合。 • 资源及其资源的关系称之为拓扑 （应用拓扑、物理拓扑） • 数据入库 自动 发现 资源管理方式有人工维护和自动发 现两种方式。流程是人工维护的一 种复杂场景和手段。
  • 10.应用管理之资源模型管理 核心模型 • CMDB分核心模型和扩展模 型。核心模型是业务、应 用、主机和程序包；扩展 模型是基于这个实例的关 联对象。 • 建立以应用为中心的资源 管理模型
  • 11.应用资源管理的三层功能结构 场 景 应 事件 管理 用 层 监控 变更 影响 分析 故障 影响 分析 应用 巡检 报告 持续交付自动化 调度 编排 作业 管理 持续 部署 数据分析 应用 容量 分析 应用 可用 性分 析 应用 体验 分析 资源 使用 分析 资 源 基础资源管理 应用资源拓扑 基础资源拓扑 应用资源管理 功 能 层 自动发现 CMDB流程 管理 资 源 管 CMDB 理 层 IP CMDB (API) • 确定CMDB的管理层次，分期建设；领导参与；核心能力覆盖。
  • 12.何为应用的资源  构建资源的过程就是构建【CMDB/IT资源】管理的过程  资源的广度决定自动化的深度  管理的资源应只包含静态数据(动态数据由监控平台处理)  因地制宜，采用弹性资源管理模型  资源的管理模型和运维组织的模型完全一致
  • 13.• 运维的困境及突破 • 应用的资源管理视角 • 应用的动作管理视角 • 应用的状态管理视角 • 应用的平台管理视角
  • 14.动作面向的角色和场景分类 DevOps • 面向DevOps • 持续交付 • 持续部署 纯Ops • 面向运维 • 业务/应用上线、下线 • 业务/应用扩容、迁移 • 业务/应用切换 • 面向角色的运维自动化
  • 15.面向DevOps的持续交付 Continuous Delivery is the ability to get changes of all types— including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way. --Jez Humble • 持续交付是DevOps的最佳工程实践 • 持续交付是精益企业的最佳工程实践
  • 16.持续交付链=IT价值链 需求队列 • 用户反馈产生的需求 • 运行持续反馈产生的 需求 持续集成 持续测试 持续部署 持续运营 • 运维标准化 • 运维平台化 • 运维PaaS化 交付队列 • 人工构件库 • 技术架构服务化 • 持续集成与测试 • 用户验收测试驱动研发 • 冒烟测试和探索性测试、非功能性测试
  • 17.持续交付流水线的整体架构 平台管理 持续交付平台 可视化平台 立体化监控平台 价值交付 版本控制、自动化、内建质量、持续改进 能力管理 配置管理 集成管理 架构管理 测试管理 环境管理 数据管理 部署管理 流程管理 管理过程 持续交付文化 数据度量文化 灰度实施 持续改进 构建实践 自动化构建；构建脚本从IDE 分离；集中放置源码；针对所 有环境构建；每日构建；快速 构建；分阶段构建 持续审查 代码复杂度 持续代码升级；减少重复代码； 判断代码覆盖率；代码复用率 持续测试 自动化单元/组件/系统/功能 测试；让测试过程可重复；执 行较快的测试；将测试快慢分 离 持续部署 一次构建，四处运行；构建结 果打上标签；执行所有的测试； 回滚部署的能力；灰度部署的 能力 持续反馈 反馈软件的服务状态；持续的 反馈机制。 部署流水线
  • 18.交付流水线整体架构 源代 码 环境配 置与应 用配置 版本控制 环境配 置与应 用配置 开发人员 查看代码度量数据 和测试失败原因 提交阶段 编译 提交测试 构建打包 代码分析 测试人员 自服务部署 验收阶段 配置环境 部署二进制包 冒烟测试 验收测试 上传 报告二进制包 元数据 二进制包 配置包 运维 一键化部署 报告元数据 二进制包 配置包 UAT阶段 配置环境 部署二进制包 冒烟测试 容量测试阶段 配置环境 部署二进制包 冒烟测试 容量测试 生产环境 配置环境 部署二进制包 冒烟测试 二进制包 配置包 人工构件库（二进制、配置库） 环境配 置与应 用配置 环境配 置与应 用配置
  • 19.发布频率 持续交付频率与能力对照表 每100天发布 一次 每10天发布 一次 每日发布 每天发布 10次 每天发布 100次 分支模型 测试 架构 发布 基础设施 数据库 在分支上开发 合并到发布分支，然后发布 后再次创建分支 由单独的质量保证部门 负责功能测试自动化 主干开发 为发布创建分支 在主干开发 从主干发布 拉动提交 请求到发布分支 在部署流水线中组织快递、完备的 自动化单元测试和功能测试 由开发人员和测试人员共同维护自动化功能测试 所有东西 一起部署 每个产品/每种web资源单独一个包 严格的SOA架构，向前和向后兼容 灰度发布、蓝绿部署、金丝雀发布 定时版本，版本火车 开发自己将变更部署到生产 可以通过收版本控制管理的脚本 来准备类生产环境 异构，运维部门 统一管理 标准化的PaaS或者IaaS、Caas 平台来交付 手动迁移 采用增量脚本变更数据库 并对回滚进行演练 设计中考虑应用对数据库的前向、后向 兼容性（采用扩展或契约）
  • 20.持续交付流水线的实现 内建质量、持续改进、变更看板 阶段 环境 动作 Dev docker或程序包 Test docker或程序包 Staging docker或程序包 Production 开发集群 server列表 部署编排 初始化系统 Data文件copy 升级应用 Data文件copy 测试集群 server列表 初始化系统 Data文件copy 升级应用 Data文件copy 执行自动化测试 发送测试报告 预发布集群 server列表 初始化系统 Data文件copy 升级应用 Data文件copy 灰度切访问路由 生产集群 server列表 负载均衡切换 初始化系统 Data文件copy 升级应用 Data文件copy 灰度切访问路由 角色
  • 21.动作Action的抽象层次  作业平台  基本变更单元，控制输入输出。类似配置管理  调度平台  支持复杂的编排调度  支持外围能力的插件化集成  场景化IT  Pipeline [结合应用交付平台，打通持续集成、持续部署、持续反馈]  主机巡检  虚拟化自动变更  故障自愈、故障现场信息采集  ……
  • 22.持续部署之层级标准化视图 应用/服务/组件 应用标准化 中间件 中间件标准化 操作系统 操作系统标准化 硬件
  • 23.持续部署之标准化XY模型 • 梳理 Y 轴(实体) • 所谓的 Y 轴，是指企业IT系 统所遵循的技术栈 从企业的技术栈入手，从宏观 上把需要标准化的实体梳理清 楚 • 构建 X 轴(属性) • 所谓的 X 轴，是指企业IT系 统每一层技术栈应该遵循的 标准 对每一层的技术栈进行深度分 析，构建出实体应该具有的属 性
  • 24.持续部署之应用标准化 X轴属性 部署路径 属主 权限 (目录、 文件) 代码 JDK √ √ √ × JBOSSEAP √ √ √ × 配置 × × 公共组件 √ √ √ √ √ 业务层 √ √ √ √ √ 日志 × × × √ ...
  • 25.Y轴实体 持续部署之应用标准化
  • 26.持续部署应用规范之5条军规 启动脚本 统一的启动脚本，通过 传入参数来匹配不同的 业务组件 日志实践 日志写到数据或者日志 卷上； 规范的输出级别、内容 格式、日志种类、轮替 周期和定期清理 实体隔离 不同的实体部署上必须 隔离 数据隔离 数据需要写到数据目录 或者数据卷上 代码和配置 代码包无状态，一次打 包，多环境流转； 配置包环境相关，甚至 可以实现配置中心
  • 27.• 运维的困境及突破 • 应用的资源管理视角 • 应用的动作管理视角 • 应用的状态管理视角 • 应用的平台管理视角
  • 28.应用数据的采集体系 可视化 质量 问题 • 一个采集组件分别采集结构化和非结构化等各类数据 • 数据需要分层，分层视图有利于建立全面的应用健康评价体系 • 采集的数据事件类数据和指标类数据
  • 29.面向故障的核心数据视图 • 基于业务访问流的可视化呈现 业务流视图 • 业务访问流的呈现是基于服务和接口服务的呈现 • 架构视图是一个完整业务和应用的全景视图 架构视图 • 架构视图是基于应用最小粒度和基于业务最大的粒度呈现 • 部署视图是一个应用和一个业务的部署视图 部署视图 • 部署视图包含了节点、组件、应用等内容 • 物理视图就是底层基础设施的完整概貌 物理视图 • 物理视图包含了机房、机柜、网络、服务器、虚拟化等信息
  • 30.何为应用的状态  状态及度量 监控是一种问题的度量 ITOA是一种面向优化的度量 度量的数据来源是指标和事件类数据 指标类数据和事件类数据分别是面向结果和过程的
  • 31.应用状态的IT运营分析体系 应用容 量分析 应用 应用可用 分析 应用性 能分析 应用健 康度分 析 • 结合数据模型，对运营数据进行场景化分析，提炼数据的价值 • 从容量分析和可用性分析给出用户决策性的判断依据 • 形成收集数据，分析数据，提供决策依据的闭环
  • 32.应用H健康指数 • 应用健康状态取决于资源和服务的健康状态 • 为每个应用建立健康度指标，用综合健康度指标反映一个应用的健 康状态
  • 33.• 运维的困境及突破 • 应用的资源管理视角 • 应用的动作管理视角 • 应用的状态管理视角 • 应用的平台管理视角
  • 34.IT服务管理平台的概念层次 运营能力层 成本优化能力 故障自愈能力 业务服务优化能力 性能优化能力 质量优化能力 用户体验优化能力 效率提升能力 连续服务能力 OaaS，运维即 服务 平台能力层 持续交付平台 智能监控平台 IT运营分析平台 安全平台 通用能力层 名字服务 GSLB服务 缓存即服务 LB即服务 存储即服务 队列即服务 配置即服务 数据即服务 引擎即服务 资源即服务 作业即服务 应用部署服务 PaaS，平台即 服务 CMDB，基础资源管理和业务信息管理 基础设施层 API Adapter Layer 设施管理 OpenStack VMware CloudStack 物理服务器 IaaS，基础即 服务 • Operation As a Service，运维及服务，是以EasyOps PaaS平台能力为基础， 实现了运维的IT能力和业务能力的对接。
  • 35.IT服务管理平台的功能图 • 以CMDB为基础，实现从自动化能力到数据化能力的全栈交付。 • 运维平台实现了运维的能力从基础设施到业务的闭环，也实现了多运维角色的能 力集中管理。
  • 36.谢 谢！