第一章：RD/OP 实际上在写同一个分布式系统
1、每个应用都是集群的一部分，每个RD都有一套自己的集群管理方式
有的设计得非常简单：一个配置文件，读取一下数据库的ip和端口
有的设计得非常复杂：使用zookeeper这样的名字服务，自己做监控，自己部署代码，自己做服务发现等
RD的视角很少考虑运维的问题，RD视角出发的集群管理基本上是以程序能够运行起来为标准的。
RD没法不考虑集群管理，因为没有这个，程序是无法独立运行的。
RD没法太多的去考虑集群管理，因为大部分的应用的开源的，无法假设实际的运维工具栈。
2、每个运维系统都是在给应用打补丁，每个OP都在给RD擦屁股
运维系统与分布式应用没有什么区别。运维系统实际上是在做adapter，把每个接入的应用建模成一样的分布式应用。
OPDEV实际上不是在写运维自动化系统，他们在写的是一个分布式系统的集群管理模块。
OP实际上不是在接入系统，而是在把各种乱七八糟，半拉子的分布式应用改造成可运维的模式。
一堆互相做法不同的系统，每个系统又由RD/OP两种角色的人各搞半拉子工程拼接而来。
=================
第二章：面向场景面向过程的思维
发布：新的版本上线
变更：所有对已有版本的改动
配置更新：变更的一种，用某种接口修改配置使其生效
扩容缩容：变更的一种，增加机器
开区合服：变更的一种，增加一个业务上的set
故障处理：变更的一种，修复线上机器的故障
过程，传文件：需要一种通用的文件传输机制
过程，执行脚本：需要一种通用的获取ip，脚本执行机制
过程，调用API：需要一种通用的调用云服务的api的机制
过程，组合：面向每个场景的每个操作，都要有一个过程。更大的组合是对一堆过程拼装。
结果是一大堆无法重用的脚本，无法审查，无法验证。bash/ant 等语言不是唯一问题，没有足够好的人来写脚本也不是唯一问题。为什么需要这么多大体上是重复脚本，才是问题。
unscalable thinking
==============
第三章：对状态进行建模
idea：对状态进行建模。比对实际的状态和预期的状态得出动作。
想法很好，但是实践起来发现这个事情其实很坑：
问题1，从上往下事无巨细的描述状态：从最上层的每个机器上运行多少个进程，到最底层的有几个文件，都有什么内容。
问题2，静态地描述全局：需要描述有多少个ip地址，每个ip上都部署了什么，每个配置文件里的依赖项都是静态确定的
问题3，动作非常难搞对：无法测试这个部署脚本。很多时候在一个空机器上运行会挂掉，但是在我的机器上运行就是成功。
问题4，跑起来太慢了，而且不可靠：需要从外网下载一堆东西，很慢。即便不用下载，运行一堆apt-get也快不到哪里去
================
第四章：docker
docker解决的问题是状态可以是一个很大粒度的东西。不用细粒度到文件级别，可以把一个进程的所有依赖打包成一个黑盒。apt-get还是yum，就没关系了。
================
第五章：名字服务，服务注册，服务发现
smartstack做的事情其实是名字服务的统一化。构建一个进程和服务级别的名字服务（大部分运维出发的CMDB，都是IP级别的），然后把所有人的名字服务全部统一成一个，可以网络依赖问题。
================
第六章：marathon & helix
这两项工具其实干的事情是类似的。与其事无巨细地描述预期的状态，不如给一定一些规则，让系统去自动决定最佳的状态是什么。给定5台机器不同负载，上面要跑10个进程，marathon会帮我搞定每台机器上跑哪些进程。
helix也是类似，告诉helix需要多少个partition，都应该是什么状态，由helix去分配。
==================
第七章：detc
现状：一堆互相做法不同的系统，每个系统又由RD/OP两种角色的人各搞半拉子工程拼接而来。用一大堆脚本，以过程化的思维去管理系统。
预期：一堆系统虽然功能不同，但是用完全一致的方式来管理。接管所有RD/OP承担的集群管理工作，全盘地处理问题。以面向状态地思维去建模，虽然仍然有脚本，但是都是原子化可复用的。
