####缘由 系统在外网开发，但测试、生产环境却在内网私有云上，两边的网络不通，像Jenkins之类的持续集成工具都无法使用。内网环境的部署都是通过手工操作的。整个项目大大小小7个包，从外网拷到内网，再备份、部署，花的时间也不少。后期随着用户访问量增加，系统横向扩展是必不可少的。应用部署在多台服务器上，这时如果还采用手工方式，那工作量将成倍增加。其实除了从外网拷到内网这一步需要手工操作外，其他的都可以实现自动化。按照谷歌SRE的标准，部署工作属于琐事，应尽量将时间减少到最小。于是这段时间整理了备份部署的流程，并编写了相关的脚本。

####脚本需求 灵活性： 系统最后将产品化，会在不同的环境下使用。脚本应体现足够的灵活性，满足在不同环境下部署的需要。

支持分布式部署： 产品中的各个应用模块都支持横向扩展，脚本需支持多服务器并行部署，当服务器增加时，部署工作量不应随之增加。

####部署流程 准备一台部署服务器，所有的脚本统一在这里管理，运行。如果没有多余的机器，也可和某一个应用共用一台服务器。备份、部署流程如下：

####单机部署脚本 为保证脚本的灵活性，把可能变化的值都写到一个配置文件里，脚本运行前会先加载该配置文件，以获取相应的参数值。

每个应用一个部署脚本，后面可以灵活组合，也可以做一个简单的人机交互界面，方便小白人员使用。

实现集中式部署，需要解决两个问题：

1. 部署服务器和各应用服务器之间实现ssh双向免密连接。方法如下： a. 用“ssh-keygen -t rsa” 命令生成公/密钥。 b. 用“ssh-copy-id -i ~/.ssh/id_rsa.pub 用户名@ip”命令把公钥复制到远程服务器。 然后在另一台服务上再操作一遍，就可实现双向免密连接

2. 脚本虽然在部署服务器上运行，但其中关键的命令是要在远程应用服务器上执行的，用以下方式实现：

   ssh root@$ccuap_server_ip  << remotessh
   # the script here will be run in remote app server
   ...
   ...
   # exit when finished.
   exit
   remotessh # don't leave space at beginning.
   

   另外，脚本中尽量不要使用rm -rf xxx，特别是像 rm -rf $path/这样的命令，有很大的风险。一旦变量path为空，就相当于“rm -rf /”, 如果又恰好以root用户执行的，那后果就相当严重了。我的办法是先mv到临时文件夹中，后面再统一清理。

####并行部署脚本 开始的想法是通过“deployXXX.sh server1 server2”这样的方式来实现多服务器部署。这种方法服务器多了也不太方便，脚本里又需要加各种判断，循环，增加了复杂度，不易维护。后来发现有并行ssh工具，并行部署的问题就变的简单了。我用到的工具是这两个：

1. mussh 该命令可以并行的在多台服务器上执行一段脚本，用法如下：

   mussh -H hosts -C xx.sh
   

   hosts文件里维护一个主机列表，每行一个主机名或ip。 xx.sh就是要执行的脚本 mussh无需安装，网上下载的压缩包，直接解压就可使用。

2. pscp 并行scp，可以同时复制文件到多台服务器上，用法如下：

   pscp -h hosts source dest
   

   网上下载pssh安装包，建议源码安装，pscp是里面的一个工具。 有了这两个个工具，把前面的部署脚本修改下，就可以实现多服务器并行部署了。

有趣的故事更容易被记住，利用场景穿透法可以让场景变得更有趣。

一个人在蹲马桶的时候，拿起了旁边的洁厕灵，背面的产品介绍是这么写的：如果你现在正在看，说明你忘了带手机。这个人觉得很有趣，把它放到了网上，结果这个品牌的洁厕灵大卖。洁厕灵不仅可以清洁马桶，还能让你打发无聊的时间，穿越了固有的场景。

窗外有人在喊：“打死，打死，反了，反了”。乍一听，以为外面在打架，探头一看，原来是丈夫在给妻子指挥倒车。

场景穿越，需要用不同的视角来观察，打破常规的思路，给人以意外的惊喜。

前两天看了18年的DevOps现状报告，下面这张图给我的印象比较深，它展示了当前实施Devops的5种方式。其中SRE方式占比最少，但是组织希望实施SRE的意愿却最高，无论CXO层、管理层还是团队，都表现出了极高的兴趣。SRE究竟具有什么特质，让大家一边向往，一边又保持距离呢？

SRE，全称Site Reliability Engineering, 是google公司对运维工程师的称呼，也用来表示google的运维方法论。SRE的核心目标是稳定（Reliability）。一般意义上的运维，类似于系统管理，以人工操作（operation）为主，但google改变了这种理念，以软件工程（Engineering）的方法来做运维，通过创造系统来维护系统运行以替代传统的人工操作。

对于开头提出的问题，我觉得大概有3点因素： ####1. google效应 google自带明星光环，只要是google出品的，总会引起人们的效仿。另外，google分布全球的服务器集群，每天需要支撑几十亿的访问。负责维护这么庞大集群的SRE团队，是如何运作的，自然很受大家的关注。

####2. 理念 系统需要人工参与的地方越多，它的稳定性就越差。SRE就是要尽量消除人工操作，特别是经常发生的，重复性的操作。google把这些操作称为琐事。关于琐事的介绍，可以参考我之前写的文章《减少琐事》。

SRE通过设计、构建自动化工具取代人工操作。传统运维团队的大小基本与所服务的产品负载呈线性同步增长。如果一个产品越成功，用户流量越大，就需要越多的人来重复进行同样的事。而成功的SRE，运维工作量保持在一定范围内，却能支持持续增长的业务规模。它们的关系如下图所示：

SRE代表了管理大型复杂服务的最佳实践，由一个简单的想法“我是一名软件工程师，这是我如何来应付重复劳动的方法”而生。

####3. 现状约束 谷歌SRE团队里有两类工程师。50%-60%是标准的软件工程师，其他40-50%基本满足软件工程师标准（具备85-99%的技能），同时具有一定程度的其他技术能力，比如，Unix系统内部细节、1-3层网络知识等。可以看出来，SRE对人员的要求是很高的，传统的运维人员大都没有开发软件工程的能力，有些甚至连linux、数据库都不是很熟悉。运维一般需要跨团队协作，针对不同的问题，由专门的团队来解决，这也是大多数公司采用的做法。

一般公司的项目，并没有google这么大的集群规模，shell脚本+现成的监控工具就能满足运维的需要，采用SRE有点大材小用的感觉。

####结束语： SRE涉及的内容很多，有技术上的，也有管理上的。本文只是涉及了点皮毛。SRE很多具体的策略，如拥抱风险、监控预警、紧急处理、on-call等等，还没来得及深入学习。感兴趣的朋友可以看看《谷歌运维解密》这本书，有时间大家一起探讨。

百度百科对战略与商业模式的定义是这样的：

战略：是一种从全局考虑谋划实现全局目标的规划。

商业模式: 企业与企业之间、企业的部门之间、乃至与顾客之间、与渠道之间都存在各种各样的交易关系和连结方式称之为商业模式。

从定义中可以看出，战略和商业模式一般都用于组织级别，对于个人来说，很少会用到。时代在发展，社会在进步，如今这两个词也有了新的定义。

大战略

只要目标与能力能够达成一致，并根据环境的变化适时做出调整，就是大战略。 —— 加迪斯的《论大战略》

每年的12月，大家都忙着做各种总结和新年展望。通过总结重新评估自己的能力，新年展望则制定下一个目标。按照加迪斯的定义，我们的新年计划应该叫做新年战略，听着是不是感觉很高大上？

我觉得这个定义的核心在于后半句，目标不是一成不变的，而是要适应时势的发展。也就是说，战略需要拥抱变化，因时制宜。 。

商业模式

李笑来在财富自由中提到了个人的商业模式，每个人都有一样东西可以卖，这东西人人都有且非常公平，就是时间。你采用怎样的商业模式来对待时间，决定了你的人生之路怎么走。

1. 按时收费

有按小时收费，有按月/年收费的，本质上都一样，通过出售一定时间的劳动来换取收入，属于一次性收费。你把时间卖给了A，就不可能同时再卖给B。要想增加收入，一个办法是多卖时间，比如，8小时卖给A，另外搞个兼职再卖4小时给B。还有就是增加单位时间的价值，本来月薪8000，通过提升自己能力，月薪翻倍。工作时间没变，单位时间的价值增加了。

1. 重复收费

通过创造产品来获得收入。时间只需要花在产品的创造上，产品成功后，不再花费时间，靠产品本身带来收入。一次性的时间投入，带来重复性的收入。香港动作影星邹兆龙2001年参演了《黑客帝国》，现在还能收到版权费，将来只要这部电影还有人看，属于他的分红就不会少。再比如，制作一个视频教程放到网上，只要有人点击，就算教程本身免费，也会带来持续的收入。

1. 购买别人的时间，为自己创造价值。

这种就是公司的形式了，通过雇佣人，利用他人的时间，为自己创造价值。

写这篇文章，其实就是想说明一点，在如今的互联网时代，“个体”的概念得到了重新的定义，其重要性甚至超过了“组织”。很多经营组织的方法也可用在经营个体上，如果做不了别人的老板，就先做好自己的老板。

著名华人设计师包益民说过，纽约这个城市好不好，取决于你有没有钱。

它在提醒我们一件事，我们对于一个事物的评价，其实不取决于它本身怎么样，而是我们有没有资源和它匹配，有没有能力享受它的好处。

所有不要公开抱怨什么，因为，只要你说什么不好，马上就暴露了一件事，就是你没有能力享受它的好处。

越是公开抱怨，就越是公开宣扬自己的缺陷。同时还暴露另一件事，就是你压根没有改善自己的能力、弥补这些缺陷的愿望。

一个人对外部的要求越高，自己的能力就越差。

抱怨不是坏事，抱怨背后是有良好的期待，通过抱怨可以理解自己的需求。抱怨之所以是坏事，因为你把满足自己需求的期待放到了别人身上，所以也和成长无缘了。

费斯汀格法则：生活中的10%由发生在你身上的事情组成，而另外的90%则由你对所发生的事情如何反应决定。

以上内容摘自逻辑思维公众号。