想起来漏掉了很重要的一个图, 关于完整的服务, 以数据库为例.
开始的时候, 我们提供数据库服务, 几乎就是把数据库建好之后交给用户就完成了. 这导致一个结果, 工作相当的没有意义. 后来经过一段时间的思考, 我总结了下面这个图, 是我认为一个服务应该包含的几个方面. 千万不要用WebService或者其他等等的系统来提要求, 我先自认相形见绌了. 不管怎么说, 这不过是个互联网公司的内部服务罢了.
"系统拓扑", 指的是数据库怎么部署(多实例还是单实例; 怎么分端口; 网络磁盘还是本地磁盘; ssd还是普通磁盘; raid; 主备机房设定; etc), 因为这项决定了系统的最大能力:
1. 稳定性和可靠性. 合理的拓扑降低出现故障和波动的可能性; 减少潜在故障; 承受故障的能力;
2. 性能. 拓扑对性能的影响是巨大的;
核心的运维系统, 在前面我提过了django/admin, 就是自动化运维的基础.
监控的重要性自然不用说, 我最喜欢的一句话是: 没有被监控的机器就是不存在的机器. 只是忘了哪位大牛说的了.
监控分内部监控和外部监控. 内部监控可以用zabbix, 在网上搜一个对应服务的template自己改改, 很快就起来了. 外部监控是指给使用这个服务的人, 提供一个页面展示一些他们会关心的监控信息, 比如qps, 数据量. 这些数据可以直接从zabbix的数据库里获取, 非常方便.
为什么要分内部监控和外部监控? 因为运维人员和外部人员关心的信息是不一样的. 举个例子: 运维人员需要在发现metrics出现变化的时候, 做很多对比: 同一个host上的其他instance怎么样? 用来确认是不是host的问题; 实例副本上变化是否一致? 用来区分是整体问题还是单一问题. 外部人员不关心, 他们需要关心"最近数据量增长有点快", "吞吐快接近设计容量上限了"这些. 因此, 数据是同一份监控数据, 但是展示的形式是不一样的.
有了规范的拓扑和内部监控, 至少这个东西能够开卖了.
入口控制在重要性上被我排在第三位, 但是要记住一点是: 入口控制是判断一个组是"提供数据库服务"还是"装数据库的"的区别.
没有入口控制, 这个服务不过是其他人的服务中的一个组件, 都不能单独维护; 有了入口控制, 就成为另一个服务的依赖服务.
我之前在入口控制上做得不好, 每次维护系统, 都需要业务配合配置调整. 后来有一些不用改配置了, 有一些还是要重启一下. 探讨个问题: 面对smart client的时候, 怎么做入口控制?
入口控制上, 我推荐直接用DNS, 不要搞VIP. VIP限制太多, 而且IP层还是太低了一些, 把硬件相关的信息留给硬件; 服务这个级别用更偏软件的域名更好. 我也不大喜欢cname, 感觉有点作, 不过无所谓, 比vip好多了.
说到DNS, 想起个问题: 1. Hadoop的域名, 应该交给公司统一的DNS服务来处理, 还是自己搭一套?
服务的长久需要靠运营, 就需要有运营的系统来支撑. 做业务开发的工程师一般都会注意这一点, 而纯的后台服务工程师比如devops就时常意识不到, 我也是过了很久才发现这个系统的必要性的.
以数据库服务为例, 最重要的几个作用:
1. 统计故障率, 处理情况, 资源规划;
2. 各种给老板看的报表 => 时刻记住老板的重要性, 好好放在心里; 其次, 老板有了这个纵观全局的系统, 就会减少在前面提到的三个系统上发表意见;
3. 作为给其他团队提供各种数据和自动化服务的接口, 以及在更大范围做系统集成时候的统一接口. 毕竟, 服务集成会涉及大量琐碎的事(比如安全检查, 规范检查, quota检查, etc), 放在核心运维系统上是不合适的;
4. 在这个系统上, 尽情地释放想要写网页做产品经理的基情吧!
PS. 在资源规划这件事上, 因为私有云IaaS的发展, 很多人觉得规划是IaaS的事, 不需要服务层面来做. 这一点我始终持反对意见. 并且还没有见到过哪一个公司的IaaS能做到不用其他人担心资源不足的, 我现在很好奇先锋G司是怎么做的.
基本上, 这几部分完成了, 可以说这个服务的大事都搞定了. 从我观察到的情况来看, 这个模型在业界的应用还是很差的, 尤其是企业内部. 真正在做对外服务的几个公司自然做得不错, 毕竟做的不好就没有用户掏钱, 然而在公司内部, 都是相当地不规范.
如果这个模型能够广泛应用, 那么对于系统的长期维护, 组织架构规范化, 想必都能有很大的帮助.