《自动化运维》阅读心得

Contact me

或者用邮件交流 jacky.wucheng@foxmail.com

前言

参考文章 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