《自动化运维》阅读心得

少于 1 分钟读完

前言

参考文章 18页PPT带你深度解读运维自动化

看完后有一些心得。

对自动化的理解深度

  • Puppet等其他CMS要做到自动化,OS和应用层的标准化是基础。
  • 标识生命周期的实时状态,需要大量的数据采集来反馈。
  • 所有自动化的本质是可视化,让所有人看到一致的服务,确保结果一致。

自动化系统存在的形式

  • 应用变更的维度:流程化,标准化,且各个子系统向上提供的API的风格要求一致。
  • 系统层次的维度:各层干自己的事,不越界,各层的交互依靠API。
  • 和业务程序的耦合程度的维度:界定的标准是“是否由业务程序直接调用”,这实现了2个目的,
    1. 看清运维平台和业务程序的分界线。
    2. 将运维和业务方的工作职责界定清晰,非耦合的由运维方全权负责,耦合的部分由开发来建设,运维只负责部署、监控等底层的工作。

当然还有其他的界定标准,例如:

  • 业务方只负责使用,不参与开发的部分,界定为运维平台的职责,其他部分界定为开发方的职责。这种模式的结果是,纯业务技术和平台技术两个阵营,业务方只需要关心实现自己的业务。例如 新浪。这里其实可以再分成:基础运维,平台运维。

开发运维平台的几个原则

  • 目标:明确全局目标,让运维,开发,测试达成共识。
  • 任务分解:运维子系统的开发,根据紧迫程度排期,在人力资源有限的情况下战线不要拖得太长。从底向上开展工作,逐一落地实现。
  • 边界界定:
    • 职能边界:平台服务的开发方,同时需要提供管理功能,只交付组件不交付管理功能的研发项目,都是低价值项目。
    • 管理边界:我对此的理解是,研发开发的系统,Administrator不是研发他们本身,而是SA,所以也就需要“职能边界”里界定的项目需要提供管理组件。
  • 插件化:作者的经验是 【应用服务层】和【架构服务层】,不要引入插件化的管理方案,过多的插件化部署,否则会让生产环境的管理最终混乱不堪最终失控。其实作者的痛点是将插件的权限开放出去之后最终不可控了。所以,应用服务层和架构服务层,底层实现可以插件化,但是对业务方提供的只是固定的功能。

自动化的场景分析

DNS GSLB

作者不建议将内部DNS和GSLB混用

  • 混用的好处:资源整合
  • 坏处:
    • 公网DNS有被攻击的风险,所以将内部DNS解耦可以规避风险。
    • 内部拓扑信息泄露,如域名-IP解析,域名规则,由此猜出内部拓扑。
  • 解决方法:软件+管理平台可以共享,内部权威DNS不对外可见。

CMDB

整个配置管理系统要做到:

  1. 数据静态化
  2. 版本化

NameService

利用zookeeper和puppet做实时的配置变更解决方案。

持续部署管理系统

一个真正的发布系统要做到哪些:

  • 版本管理
  • 环境管理
  • 配置管理
  • 生命周期管理
  • 等等

全局运维平台的管理系统

  • 流程 + 执行器
  • 业务上线、业务下线、业务扩容、业务缩容
  • 应用升级

API的实现

  • 系统级别或者接口级别的鉴权,不可完全开放

运维团队模型

能力模型

  • 业务运维
  • 运维开发
  • 技术研究

组织架构模型

作者给出的组织架构模型

  • 业务运维
  • 运维开发

价值驱动模型

pass

团队技能模型

腾讯的技能模型雷达图

运维开发的RoadMap

  1. 从单独的公共服务平台入手。DNS,LVS,CMS等。
  2. 制定相应规范,让所有人共同遵守。
  3. 组织虚拟研发小组(业务运维+运维开发),开展工作,提升团队战斗力。

运维平台的子系统组成

  • DNS系统
  • CMDB系统
  • NameService系统
  • 持续部署系统
  • 监控系统
  • 业务调度管理系统(存疑)

可进一步讨论的点

  • Top View中的部分内容。
  • 文章里的业务上线流程图可以深挖。
  • 运维和开发的职责界定标准。
  • 插件化的程度。

其他摘录

  • 对于监控采集来说,应用程序自己开放端口或者/proc/等形式直接暴露runtime信息比汇聚日志再分析好的多。
  • 当然日志批量离线分析也是非常必要的,必经如上方法暴露的信息不会特别多。

会共用的子系统

  • 命令管道
  • metric采集渠道

Top View

运维平台架构图

游戏平台发布次数统计

DNS管理后台

CMDB管理后台

NameService

留下评论

您的电子邮箱地址并不会被展示。请填写标记为必须的字段。 *

正在加载...