运维会比开发更加重要
运维的发展日新月异，曾几何时，运维仅仅是被认知为跑机房，装系统，设计网络，给开发擦屁股。但是现在运维变得极度重要，运维职责也更加细化，譬如稍大点的公司就将运维划分为基础运维，网络运维，DBA, 应用运维，架构师。其实我个人认为系统架构师应该都安排在运维里，开发团队应该率属于运维团队才好。
进入云时代后，中等层次的运维慢慢会被淘汰，底层次的运维会越来越少，高水平的运维需求量则日益增长。为什么这么说呢？云时代背景下，低层次的运维主要按章循干活即可，而高层次的运维则需考虑系统架构设计，以及构建自动化的系统。这其实是反应对运维的要求会越来越高，不但要掌控产品的稳定性，做好服务保障的最后一公里，还要具有系统设计的能力。
运维现有发展方向的问题
运维也越来越朝着平台化，自动化，自助化方向发展。这种发展方式虽然可以解决问题，但是会导致碎片化以及难以标准化，不可复制，对生态也是不利的。
所谓碎片化指的是针对性的开发工具套件解决问题，比如为了解决配置问题，开发了个配置系统，比如为了部署，开发了部署系统，为了管理应用，针对不同类型的应用开发管理系统。所有这些系统都是为了解决特定一类问题而开发的，系统孤岛，很难让他们产生关联。
导致这种现象的原因在于，开发人的能力本身不足，缺乏全局观，或者各个系统本身的属性特质就导致他们难以关联。每个系统就像一个碎片，所以我们说这事碎片化。
标准化指的是，我开发的配置系统很可能跑到另外一家公司，就不能用了，因为我只是针对我的环境开发好配置系统就行，这里就带来的另外一个问题就是不可复制，也就是我开发的系统没办法很容易移植到别的地方去。
对生态不利，则是指，因为无法标准化，难以复制，每家公司各自开发自己的，无法形成社区，大家致力于统一的运维工具，则必然影响运维生态的发展。
之前我写过一篇文章，谈及如何用大数据思维做运维，当然这篇文章有他自己的局限性，只是谈及了运维监控，灌输一种 data based 的理念。
前面我们提及了运维发展现状，以及现有的发展模式带来的问题，解决的方式就是 Distributed OS + Data Based：：
随着分布式相关应用慢慢成熟，尤其是大数据的崛起，对服务器有了更多的需求，以资源为粒度的管理需求也变得更加迫切，于是有了Google Borg,开源的则有Mesos,Yarn等。Google Borg 是个典型的。我们所有的运维需求都应该基于Borg去做。开发的服务交给Borg，后续的服务生命周期（扩容、缩容、调度）都由Borg统一接管，服务被Borg部署到哪个IDC、哪个服务器，研发人员不用关心。这个是系统层面的。当然类似Borg的 Mesos,Yarn等，都是追求一个动态调度的过程，我们也可以完全利用Borg,指定将应用安装在哪些单元(服务器群组)上，从而能够接管所有的服务。
这样，所谓前面我们提及的配置系统，部署系统，服务器监控都是在Borg提供的基础服务。就好比单机系统，你通过它安装，运行，关闭，卸载应用，你可以看服务器的资源使用情况。Borg 也是完全一样的。
也有人会说，很多应用的安装部署是很复杂的，而且如果使用了Borg其实就使得应用必须去适配Borg才能被管理。经过我们的实际实践，大部分应用都不需要对应用进行更改，也不需要对Borg进行更改，就可以部署和管理起来。复杂的比如Hadoop体系的安装，则需要Borg进行一定程度的支持，我们抽象出了一套应用的部署方案，只要简单的写一些描述文件，Borg拿到Hadoop的发型包，就知道如何安装和管理他们了。如果你需要对Hadoop做更细致的增强或者管理，你可以开发一个第三方应用，然后通过Borg安装去管理。Borg提供了交互的API,你可以通过这些API去管理Hadoop如果生命周期，而无需知道Hadoop安装在哪。
现在很流行的容器技术，也被广泛的被Mesos/Borg调度，对Borg来说这是以资源为粒度的应用，我们前面提及的，则是以服务器为粒度的应用。
前面讲的是基础平台层面的，我们其实更多的是要对应用进行更细致的观察。在Borg之上的应用可以是非常复杂的，应用的关联也是非常复杂的，微服务的兴起导致链路非常长，所以我们有了全链路追踪的需求。一切服务都是为了帮助数据进行流转和变换，服务的状态也都反应在数据流上，这种瞬态和终态的量是非常大的，所以我们需要借助大数据的思维去做处理。
到这里就可以参考大数据思维做运维灌输的概念了。
所以未来运维可以完全依托一个固定的分布式操作系统，在其上开发各种运维工具，利用大数据相关的理念和工具，监控，追踪，分析服务的状态，解决现有的运维工具碎片化，难以复制，难于贡献生态的问题。
运维的发展日新月异，曾几何时，运维仅仅是被认知为跑机房，装系统，设计网络，给开发擦屁股。但是现在运维变得极度重要，运维职责也更加细化，譬如稍大点的公司就将运维划分为基础运维，网络运维，DBA, 应用运维，架构师。其实我个人认为系统架构师应该都安排在运维里，开发团队应该率属于运维团队才好。
进入云时代后，中等层次的运维慢慢会被淘汰，底层次的运维会越来越少，高水平的运维需求量则日益增长。为什么这么说呢？云时代背景下，低层次的运维主要按章循干活即可，而高层次的运维则需考虑系统架构设计，以及构建自动化的系统。这其实是反应对运维的要求会越来越高，不但要掌控产品的稳定性，做好服务保障的最后一公里，还要具有系统设计的能力。
运维现有发展方向的问题
运维也越来越朝着平台化，自动化，自助化方向发展。这种发展方式虽然可以解决问题，但是会导致碎片化以及难以标准化，不可复制，对生态也是不利的。
所谓碎片化指的是针对性的开发工具套件解决问题，比如为了解决配置问题，开发了个配置系统，比如为了部署，开发了部署系统，为了管理应用，针对不同类型的应用开发管理系统。所有这些系统都是为了解决特定一类问题而开发的，系统孤岛，很难让他们产生关联。
导致这种现象的原因在于，开发人的能力本身不足，缺乏全局观，或者各个系统本身的属性特质就导致他们难以关联。每个系统就像一个碎片，所以我们说这事碎片化。
标准化指的是，我开发的配置系统很可能跑到另外一家公司，就不能用了，因为我只是针对我的环境开发好配置系统就行，这里就带来的另外一个问题就是不可复制，也就是我开发的系统没办法很容易移植到别的地方去。
对生态不利，则是指，因为无法标准化，难以复制，每家公司各自开发自己的，无法形成社区，大家致力于统一的运维工具，则必然影响运维生态的发展。
这些问题总结起来，其实就是缺乏一个具有一定规范的容器，将所有的需求框起来东西。
之前我写过一篇文章，谈及如何用大数据思维做运维，当然这篇文章有他自己的局限性，只是谈及了运维监控，灌输一种 data based 的理念。
前面我们提及了运维发展现状，以及现有的发展模式带来的问题，解决的方式就是 Distributed OS + Data Based：：
- 使用 Distributed OS 抽象出应用的部署/管理/生命周期监控/自动化体系
- 使用 Data-Based 思想inspect 应用内部状态,当然也包括Distributed OS，做好监控，报警，容量规划等。
随着分布式相关应用慢慢成熟，尤其是大数据的崛起，对服务器有了更多的需求，以资源为粒度的管理需求也变得更加迫切，于是有了Google Borg,开源的则有Mesos,Yarn等。Google Borg 是个典型的。我们所有的运维需求都应该基于Borg去做。开发的服务交给Borg，后续的服务生命周期（扩容、缩容、调度）都由Borg统一接管，服务被Borg部署到哪个IDC、哪个服务器，研发人员不用关心。这个是系统层面的。当然类似Borg的 Mesos,Yarn等，都是追求一个动态调度的过程，我们也可以完全利用Borg,指定将应用安装在哪些单元(服务器群组)上，从而能够接管所有的服务。
这样，所谓前面我们提及的配置系统，部署系统，服务器监控都是在Borg提供的基础服务。就好比单机系统，你通过它安装，运行，关闭，卸载应用，你可以看服务器的资源使用情况。Borg 也是完全一样的。
也有人会说，很多应用的安装部署是很复杂的，而且如果使用了Borg其实就使得应用必须去适配Borg才能被管理。经过我们的实际实践，大部分应用都不需要对应用进行更改，也不需要对Borg进行更改，就可以部署和管理起来。复杂的比如Hadoop体系的安装，则需要Borg进行一定程度的支持，我们抽象出了一套应用的部署方案，只要简单的写一些描述文件，Borg拿到Hadoop的发型包，就知道如何安装和管理他们了。如果你需要对Hadoop做更细致的增强或者管理，你可以开发一个第三方应用，然后通过Borg安装去管理。Borg提供了交互的API,你可以通过这些API去管理Hadoop如果生命周期，而无需知道Hadoop安装在哪。
现在很流行的容器技术，也被广泛的被Mesos/Borg调度，对Borg来说这是以资源为粒度的应用，我们前面提及的，则是以服务器为粒度的应用。
前面讲的是基础平台层面的，我们其实更多的是要对应用进行更细致的观察。在Borg之上的应用可以是非常复杂的，应用的关联也是非常复杂的，微服务的兴起导致链路非常长，所以我们有了全链路追踪的需求。一切服务都是为了帮助数据进行流转和变换，服务的状态也都反应在数据流上，这种瞬态和终态的量是非常大的，所以我们需要借助大数据的思维去做处理。
到这里就可以参考大数据思维做运维灌输的概念了。
所以未来运维可以完全依托一个固定的分布式操作系统，在其上开发各种运维工具，利用大数据相关的理念和工具，监控，追踪，分析服务的状态，解决现有的运维工具碎片化，难以复制，难于贡献生态的问题。
