注：本文要求读者对Ansible和 Jenkins有一定的认识。 题记: 幸福的家庭都是相似的 不幸的家庭各有各的不幸 行业内各巨头的自动化运维架构都各种功能各种酷炫，如下图，让人可望不可及。现在最终的样子大家都知道了，但问题是如何根据自己团队当前的情况一步步向那个目标演进？ 笔者所在团队，三个半开发，要维护几十台云机器，部署了十来个应用，这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上。分支管理也清一色的 dev 分支开发，测试通过后，再合并到 master 分支。生产环境的应用配置要登录上具体的机器看才知道，更不用说配置中心及配置版本化了。 对了，连基本的机器级别的基础监控都没有。 我平时的工作是 50% 业务开发，50% 运维。面对这么多问题，我就想啊，如何在低成本情况下实现自动化运维。本文就是总结我在这方面一些经验和实践。希望对读者有帮助。 别说话，先上监控和告警 事情有轻重缓急，监控和告警是我觉得一开始就要做的，即使业务开发被拖慢。只有知道了当前的情况，你才好做下一步计划。 现在市面上监控系统很多：Zabbix、Open-Falcon、Prometheus。最终作者选择了 Prometheus。因为： 它是拉模式的 它方便使用文本方式来配置，有利于配置版本化 插件太多了，想要监控什么，基本都会有现成的 以上三者，我基本都要重新学，我为什么不学一个 Google SRE 书上推荐的呢？ 之前我们已经介绍过，人少机器多，所以，安装 Prometheus 的过程也必须要自动化，同时版本化。笔者使用的是 Ansible + Git 实现。最终样子如下： 这里需要简单介绍一下： Prometheus Server 负责监控数据收集和存储 Prometheus Alert manager 负责根据告警规则进行告警，可集成很多告警通道 node-exporter 的作用就是从机器读取指标，然后暴露一个 http 服务，Prometheus 就是从这个服务中收集监控指标。当然 Prometheus 官方还有各种各样的 exporter。 使用 Ansible 作为部署工具的一个好处是太多现成的 role 了，安装Prometheus 时，我使用的是现成的：prometheus-ansble 有了监控数据后，我们就可以对数据进行可视化，Grafana 和 Prometheus 集成得非常好，所以，我们又部署了 Grafana: 在 Grafana 上查看 nodex-exporter 收集的数据的效果图大概如下： 可是，我们不可能24小时盯着屏幕看CPU负载有没有超吧？这时候就要上告警了，Promehtues 默认集成了 N 多告警渠道。可惜没有集成钉钉。但也没有关系，有好心的同学开源了钉钉集成 Prometheus 告警的组件：prometheus-webhook-dingtalk。接着，我们告警也上了： ...

题记：既生亮何生瑜。 摘要：标题虽然是为了解释有了 IP 地址，为什么还要用 MAC 地址，但是本文的重点在于理解为什么要有 IP 这样的东西。本文对读者的定位是知道 MAC 地址是什么，IP 地址是什么。 一开始时，网络中的机器并不多。大家都连到同一个集线器就可以了，就可以实现互通。这时，机器 A 发消息到机器 B ，消息头里附上机器 B 的MAC，集线器收到消息后就广播给所有连到集线器的机器。 机器 C 收到消息，发现消息里的 MAC 地址和自己的不一样，就丢弃。机器B发现消息里的 MAC 地址和自己一样，就收到下并解析。 这样机制带来问题很明显：首先每次广播，给所在网络带来不必要的浪费。所以，就出现了交换机。它能识别消息里的目标 MAC 地址后，直接就消息丢到机器 B 所连接的端口中。另一个角度，交换机必须记住所有的 MAC 地址和端口之间的关系。 这样的机制在网络规规模小的时候是高效的。但是当网络规模扩大到全球的时候，不可能让一台交换机记录下全球这么多的网络设备，也不可能让全球的机器连接到一台交换机上。 那如果是多台交换机呢？ 想像一下，你是斯坦福的学生，你的电脑 x 的网络直连的是学校的交换机，而学校的交换机又连美国国家网络交换机。而美国国家网络交换机又直接的是中国国家网络交换机，中国服务器 y 直连的是中国国家交换机。 你想访问中国的服务器 y 中的资源。你了解到服务器 y 的 MAC 地址是00:0C:29:01:00:12，所以你在消息里附上这个 MAC 地址。 学校交换机收到消息后，拿到 MAC 地址后就愣了，这是要发给谁啊？因为中国服务器 y 并不是直连学校交换机的。这时，学校交换机有一个选择，就是收到不明的 MAC 地址时，一律转发给默认端口。斯坦福交换机就将消息转给美国国家交换机。 美国国家交换机同样发愣了，因为没有这条 MAC 地址对应的端口。它又直接向默认端口：中国国家网络交换机。 中国国家网络交换机收到消息，发现自己记录了 MAC 地址 对应的是服务器 y。就直接将你这位斯坦福学生的消息转发到服务器 y 所连接的端口。 最终，我们的服务器 y 终于收到来自美国斯坦福学生的资源访问请求。 ...

想法 历史原因，我们一直使用的是阿里云经典网络的 ECS，疲于业务的开发及人力不足，一直没有特别大的动力迁移到 VPC 下。 而经典网络下的 ECS 的公网 IP 是收费的，而且没有公网 IP 有时会不方便。 购买公网 IP 时的费用 未购买公网 IP 时的费用 如果是按月购买，每个月将节约：296 - 273 = 23 元。 而我们的大多服务是内网使用的，所以，公网 IP 的申请完全是浪费。 可是，我们有时，还是需要公网下载一些东西的。这时怎么办呢？ 我的方案是：没有公网 IP 的机器，使用 HTTP 代理就可以上网了。 当然，哪些机器需要上网，基于安全上的考虑，需要读者自己决定了。 怎么做？ 我的具体实现方便使用 Squid 搭建 http proxy 服务。其他机器通过配置环境变量配置，笔者是通过 Ansible 初始化机器时配置的： - name: use httpproxy lineinfile: path: "/etc/profile" line: "<<item>>" with_items: - "export http_proxy=http://<< httpproxy.host >>:<< httpproxy.port >>/" - "export https_proxy=http://<< httpproxy.host >>:<< httpproxy.port >>/" when: is_use_httpproxy is defined and is_use_httpproxy == 'True' tag: httpproxy 关于 Squid Http Proxy 服务，笔者同样是使用 Ansible 搭建，具体不细表，看官可以自行看代码：Squid-ansible。 ...

All problems in computer science can be solved by another level of indirection – David Wheeler 计算机科学中的任何问题，都可以通过加上一层逻辑层来解决。– David Wheeler 总之，分层就是有好处 在计算机领域，“分层” 概念无处不在。比如 web 开发时的 MVC ，网络编程时的 OSI 参考模型和 TCP/IP 协议族。 但是为什么要进行分层呢？不同的书有不同的说法。 在《图解TCP/IP》这本书这样说： 在这一模型中，每个分层都接收它下一层所提供的特定服务，并且负责为自己的上一层提供特定的服务。上下层之间进行交互时所遵循的约定叫做“接口”。 在我看来，说了等于白说。:-P 而《企业应用架构模式》开篇第 1 章是这样说的： 在分解复杂的软件系统时，软件设计者用得最多的技术之一就是分层。 当用分层的观点来考虑系统时，可以将各个子系统想像成按照“多层蛋糕”的形式来组织，每一层都依托在其下层之上。在这种组织方式下，上层使用了下层定义的各种服务，而下层对上层一无所知。另外，每一层对自己的上层隐藏其下层的细节。 Marting Fowler在第 1 章后面，又举了一个表现层，领域层，数据源层的例子。但是个人认为依然没有把为什么要分层说透。 对于为什么要分层，我见过的大多数文章说的只是它带来的好处。比如下层修改实现，不影响上层使用；分离关注点等。但是为什么会带来这些好处？看似很傻的一个问题，其实很难回答。 两个例子帮助你认识“分层” 我们先通过两个例子给大家一些感性的认识。 自动驾驶 用分层的思维来看开车这件事情是这样的： 分层 具体内容 人的意图 前行，不上坡，右转弯 人的操作 踩着油门，瞥一眼后视镜，方向盘打右 汽车运行 根据踩下油门的程度，发动机输出动力，而方向盘打右转动转向拉杆 发动机 进气，压缩，点燃，排气 更底层省略…. 更底层省略 ….. 因为有了分层，当我们要实现自动驾驶汽车时，要解决的就只是“人的操作”这一层的问题，而不需要实现“人的操作”以下所有的层，也就是不需要自己从头造汽车（不是绝对，但是绝对不需要从头造所有的部分）。 IoT 云云对接 总要举一个软件开发领域的例子吧。我们举一个 IoT 云云对接的例子。 当第三方云想控制 M云的空调时，系统的外观是这样的： ...

从聊天说起 有一次和朋友聊天，他说他们有一次部署出事了，影响还挺大，那次事故后，他们公司对于部署流程增加了更多的审批。 当朋友说完前半句时，我已经猜到下半句，那是很多公司或个人会做出的反应。至于为什么会做出这样的反应，我也不知道。 我问：为什么那次部署会“出事”？ 他说：当时部署的人忘记了那台机器上有一条 Iptable 规则，导致了事故。 我就在想，如果有人审批，那次事故就不会发生吗？审批的人就知道那台机器上有一条规则导致事故的发生？然后驳回这次部署吗？连一线的开发和运维都忘记了的 Iptable 规则，“高高在上的审批领导”就更不知道了。 题外话：增加审批流程并不能避免这次事故，只不过当出现事故时，可以更好的定责。然而我又好奇了，这种“审批”是为了解决问题，解决什么问题？，还是为了逃避责任？谁逃避了责任？谁又有责任？ 对于这类问题，我心里已经有数了，但想知道这位朋友的回答，就接着问：那么怎么杜绝这类问题呢？ 他说：因为那条 Iptable 规则的设置太久远了，是谁都记不起。如果能把每次部署的步骤记录下来，这样下次部署的时候，过一下以前的部署记录，就会知道那个 Iptable 规则了。（作者：大概原意，已经记不清原话） 这位朋友说的做法，我之前待的一个团队的做法也差不多：会有一个页面专门记录下每次部署的步骤，步骤由开发人员写，然后由运维人员执行。只是我不知道他们会不会回顾之前所有针对这台机器的部署步骤。 这个团队里有某某大型互联网公司来的架构师和某财务软件公司来的运维，所以，我不负责地推测，我们这个行业很多公司对于配置的管理还没有达到足够的重视，也没有正确的看待。 我笑了，接着问朋友：那我要知道当前机器的“最终状态”，是不是要找出所有部署记录，还要过滤出对这次部署有影响的每一个细节？比如那条 Iptable 规则。 接下来的对话细节已经记不清，也不重要了。重要的是找出针对这类运维事故根本原因及解决办法。 我个人认为这类问题的根本原因在于： 配置管理的失控： 已经没有人完整知道线上环境配置是什么了？要了解时，只能一个个查。 测试环境与生产环境的配置不一致： 如果那位倒霉的同学在测试环境部署出现这样的问题，到生产环境部署时，自然就会注意相关配置项了。 以上只是我个人认为的，不一定正确，欢迎各位读者讨论。 那如何杜绝这类问题呢？ 这两个原因可以看作一个，也可以看作两个。但方法都是一样的： 使用声明式的配置管理方法，而不是脚本式 版本化这些声明的配置 所有环境使用同一套装配置管理方法 使用声明式的配置管理方法，而不是脚本式的 脚本式的配置管理是这样的： apt-get install build-essential apt-get install libtool cd /usr/local/src wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.37.tar.gz tar -zxvf pcre-8.37.tar.gz cd pcre-8.34 ./configure make make install 而声明式的配置管理是这样的： # ./ansible-nginx/tasks/install_nginx.yml # 使用这个7-0.el7版本的yum包 - name: NGINX | Installing NGINX repo rpm yum: name: http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm # 当前机器的nginx的状态应该是最新版本 - name: NGINX | Installing NGINX yum: name: nginx state: latest # 当前机器的 nginx service 的状态应该是已经启动的。至于如何确保 nginx 这个 service，当前是什么状态的，又是如何启动的，我们不需要关心。 - name: NGINX | Starting NGINX service: name: nginx state: started 声明式的配置里写的是当前环境的“状态”，语意上，声明式的配置不论你执行多少次，你得到最终的“状态”就是你所声明的，这也就实现了《持续交付》里说的： ...

没有想到，这本教子经典的书里，除了教我如何与孩子实现真正有效的沟通，还带给我管理方面的启示。 关于情感 当孩子处于强烈的情感中时，他们听不进任何人的话。他们不会接受任何意见或安慰，也无法接受任何建设性的批评。他们希望我们能够理解他们心里在想什么，希望我们明白在那个特别的时刻他们的心情。 员工之间难免会有摩擦，当出现这种情况时，我们可以说出各方的感受，引导各方相互理解对方的心情。进而将讨论焦点拉回问题的本质。 指导孩子时，我们陈述问题以及可能解决问题的方法。我们不会针对孩子本人发表任何观点。 比如当员工出现工期延迟时，我们首先要做的是陈述这一事实，听听他自己的表述，再讨论问题，而不是指责。 关于说真话 为什么孩子会撒谎？他们撒谎有时是因为他们不被允许说出真相。 想想我们所在企业是否允许员工说出真相了？是什么机制导致员工撒谎，不愿意说出真相。有办法改进吗？ 如果我们希望教育孩子诚实的品德，那么我们必须作好心理准备，既要听让人愉快的真话，也要听让人不高兴的真话。 如果我们的管理者只喜欢好听的话，那么，员工就只会说好听的话。我常常会想为什么有些管理者会只喜欢听好听的话。为什么呢？因为好听的话让人感觉良好，还是因为听到不好听的，代表自己的权威受到威胁了？ 简而言之，我们不能激发孩子防御性的撒谎，我们不能有意制造让孩子撒谎的机会。 是的，我们在进行组织设计时，要考虑如何才能不激发员工的防御性撒谎。我个人目前能想到的就是在企业中“培育”一种说真话无罪的文化。 关于责任感 责任感的培养可以从孩子很小的时候就开始。 在我看来，员工的责任感可以从小事开始，在平时进行，而不是集中在一场大型“洗脑会”中进行。 培养孩子的责任感，就是要在跟他们有关系的事情上让他们有发言的机会，如果必要，让他们自己作出选择。 管理层常常报怨员工对公司产品没有责任感。但是孰不知，员工对公司产品没有责任感的根本原因是员工常常只能“服从”，没有任何对公司产品进行发言的机会。 员工有发言权，但最终选择权是产品Leader的。弄清发言权和选择权两者之间的责任范围很重要。 我们应该故意制造一些场景，让孩子自己作决定。父母选择场景，孩子作出选择。 作为技术Leader，我们其实可以大胆让员工自己做一些技术决策。一是让他们更有责任感，二是培养员工将来能独立做技术决策。 关于聆听 父母需要开明的思想和豁达的心胸，这样才能倾听到所有的事实，不管它们是让人高兴还是让人讨厌。 “聆听”在我看来是最难做到的，因为我总是那么容易先入为主。同时，我们在聆听时，可以承认对方的感受，但是不一定要同意。 小结 有人说了，员工不是孩子，不能像小孩那样“带”。然而，很多人的某些方面就是孩子，我们必须面对。你招的是他整个人，而不是他的某部分。 前两年看完这本书时，我的个人感受：带小孩和带团队有几分相似。要培养他们，要处理他们之间的矛盾，一样要处理他们的情感，还要给他们发言权……然而，带小孩和带团队都知易行难，大家相互勉励。 强烈推荐各位亲自阅读这本书。

说在前面 在《持续交付》的第二章配置管理的小结里说到： 配置管理是本书其他内容的基础。没有配置管理，根本谈不上持续集成、发布管理以及部署流水线。它对交付团队内部的协作也会起到巨大的促进作用。 再怎么强调配置管理的重要性也不为过，特别是在多环境下。然而大家都知道重要，又少有人告诉我们具体如何做，所以实在难受。 本文总结了我在多环境配置管理实践方面的一点心得，希望对大家有帮助。 Ansible 介绍 你可以简单地把它理解为一个自动化运维工具。本文将会使用这个工具下 inventory 概念来实现多环境配置。简单一点来说，inventory是一个文本文件，你可以在这个文件里记录下所有的机器，并对这些机器进行分组（分类）。 当然，其它的自动化运维工具也可以使用同样的思路来实践。本文只以 Ansible 为例。 例子 比如我们有两个环境，分别有一台机器。使用Ansible的 inventory 来管理这些机器，就会像下面这样： ## inventory [aws-prod-app] 10.171.32.158 [aws-test-app] 10.161.158.221 所有的 app 应用都是同一份代码，而且都会涉及操作数据库。当然，不同环境下的 app 读取的数据库的配置项的值是不样的。比如 aws-test 环境下配置是 db: url: test.mysql.url username: testu1 password: passwordtest 而生产环境 aws-prod 环境下配置： db: url: prod.mysql.url username: produ1 password: passwordprod 这时，因为机器少，我们可以使用 Ansible 的 inventory 变量实现不同环境的配置隔离，比如： ## inventory [aws-prod-app] 10.171.32.158 ## [分组名:vars] 这样的写法是 Ansible inventory的约定 ## 按照这个约定来写，Ansible就可以识别了 [aws-prod-app:vars] db.url = test.mysql.url db.username = testu1 db.password = passwordtest [aws-test-app] 10.161.158.221 [aws-test-app:vars] db.url = prod.mysql.url db.username = produ1 db.password = passwordprod 接着，如果环境上要部署新应用呢？而且还是很多呢？我们的 inventory 就会变成这样： ...

坊间一直流传着“康威定律”的概念，但是都是鲜有人能说出真实的反应这一“定律”的例子。本文则尝试弥补这一空缺。 本文本为几部分： 康威推论的历史：有必要了解它的历史 康威推论的定义：《人月神话》也只是转载康威的话 康威推论的例子：我的真实经历 启示 康威推论的历史 1967年，一位名叫梅尔文康威（Melvin Conway）的早期计算机科学家、程序员及黑客向《哈佛商业评论》提交了一篇名为“组织是如何进行发明创造的？”的文章，但是立刻被退稿了，理由是他“没能证明该理论”。 对于软件设计界来说，幸运的是这篇文章随后被Datamation杂志（当时一流的IT杂志）接受，并于1968年发表。后来，Fred Brooks在其开创性作品《人月神话》中，将康威的某些理论归纳为“康威定律”，这个名字就这样流传了下来。 以文内容来自：《软件之道——软件开发争议问题剖析》。 康威推论的定义 我们来看看康威推论的原文 How Do Committees Invent? (1968) 最后的总结： The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. 按《软件之道》里的大白话来说就是： 任何组织设计出来的系统（此处指广义的系统）的结构都会照搬这个组织的沟通。 说实在的，如果没有经历过，我说的以下两个例子，真心很难体会到康威所表达的。下面，是两个现实鲜活的例子，我正在经历的。 康威推论的例证 例证一：错误码的设计 背景是某团队针对同一业务，有Android和iOS两个平台的SDK。 Android SDK和iOS SDK开发人员，他们对于同一业务错误，设计出了两套装错误码。比如对于登录时用户名或密码错误，Android给出的错误码是230，而iOS给出的错误码则是8100。 为什么会出现两套装错误码系统呢？明明可以使用一套装就可以了。当然可能会有历史原因。但是据我观察，可以肯定的是，他们在设计软件时，并没有就“错误码”达成共识。 有趣的是，他们是同一个团队。居然还会出现康威现象。如果康威推论是正确的，那么，即使同一个团队下，也会出现不同的沟通结构。 如果这个例证有些牵强，下面这个例证更能说明事情。 例证二：IoT系统的设计 IoT系统有其特殊性。通常它需要进行硬件端、移动端（App）、云端这三端的配合才能更好的完成事情。以空调为例： 2017年前，硬件端和移动端是（相当于，其实不是）一个团队，而云端则是由另一个公司负责。而真正业务的决定权在硬件端和移动端。所以，平时沟通上，只有硬件端和移动端的事，云端只不过是负责转发。所以，云端的系统设计的最终结果就是一个管道：硬件端给我什么，我就直接转给移动端，移动端给我什么，我就直接转给硬件端。如下图： ...

摘要 本文内容主要来自《门后的秘密——卓越管理的故事》，英文名：Behind Closed Doors Secrets of Great Management。在2013年第一次看这本书时就感受益匪浅，现在又重新看，越发觉得这本书写的都是大实话。非常推荐读者亲自去读。 如何进行有效的指导 指导也是管理者工作内容的一部分，但它着重于提高技术水平和能力。指导是一种帮忙与被帮忙的关系，所以一定要确认对方想要得到你的帮忙。 指导常常被忘记是管理者工作的一部分。因为管理者本身也会有能力不足的地方，“指导”的过程会暴露这些不足给下属。所以，设计组织时，要想办法让“暴露不足”成为常态，而不是羞耻。 有效的指导的一些准则： 帮助员工想出备选方案 有些管理者会想：如果还要我帮他想出备选方案，我还招他做什么。这是老旧的管理思想。我个人有以下理由需要帮助员工想出备选方案： 1. 避免失控，因为你了解方案的上下文，你才有能力判别是否失控。 2. 员工掌握的信息不足，无法做出最优方案。比如如果他不知道公司在长期业务的发展，是不会知道架构上哪些方面应该更灵活，哪些方面应该更固定。需要管理者帮忙他。 3. 与员工协作，而不只是丢一个点子。 就每一个备选方案的影响进行讨论。不要试图得到某一特定结果；应该鼓励对方从他的视角尽可能深入地去探索每一个备选方案。表达你的观点，但应让你的指导的这名下属根据自己所需，做出选择。 这个过程，其实，也是管理者学习的过程，学习别人的思考过程，同时，也可以从“思考过程”级别对员工进行指导。 制定行动计划 在一对一的会谈时，跟进这一行动计划找出成功的部分，对不成功的方法做出分析，尝试新的技术或者行为。完善并提高奏效的方法，纠正没有起到作用的方法。 在我的经历中，鲜有组织会对过去做这些分析总结。因为有不少组织文化是不愿意面对失败过去的。也不愿意让员工知道自己的失败，有一部分原因是怕员工知道这些失败，对组织没有信心。 **小小结：**当一个管理者本身能力不足，就谈不上有指导。比如，你根本就不懂SQL，谈何指导下属提升SQL性能的优化；还有一种情况就是管理者有能力，但不懂得如何有效指导，这是一种浪费。设计组织时，应该考虑如何帮忙这类员工。 有“绩效管理”思维的人可能会想，让“指导”成为KPI的一部分不就可以了？但是，如何设计这项KPI呢？我个人认为，让“指导”成为组织文化的一部分才是解决之道。 成功地分配任务 需要分配任务的理由： 你不可能每件事都亲力亲为，总有一天你需要将管理类或者技术类工作分配给其他人。（不要认为这做是偷懒逃避责任，你是在给别人提供机会。） 在行业内经常听到：教会他做的工夫，我自己都做完了。我们需要做办法说服这类员工。 但是为什么会出现这样的现象呢？因为他所在的组织没有“分享”的文化。更有甚者，某些组织或管理者会抑制分享文化，因为分享文化提高了员工能力的透明度，最终会暴露出组织或管理者本身能力的不足。 成功地分配任务的一些准则： 明智地选择你的分配任务对象。这名员工应该想要承担更多的责任，并已经确认了自己的职业发展方向，这项工作正好适合他的职业发展方向。不要选择对这项工作不感兴趣的下属接受任务。 高高在上的管理者是达不到这一准则的。因为他根本不了解自己的下属职业发展方向。 阐明你对这项工作的期待：什么样的成果才你能接受的。 在软件行业，特别是互联网行业，很多管理者也不完全知道自己对某项工作的期待。这不重要，重要的是管理者应该将这一点表明给下属听。 明确表明不被允许的方法 确定阶段性里程碑。当你做出分配工作的决定后，确保这一决定至少分为两部分：做出备选方案；选择其一。一定要表明哪一（些）部分是你分配下去的，如果在这两部分工作之间的某一点，你想进行检查，请明确地提出来。 这一点非常重要。“结果导向”的管理方式大行其道，这给很多管理者不进行过程管理的理由（这类人常常将“我只要结果，不管过程”这句话挂在嘴边）。同时，要确定阶段性里程碑，是需要有相关业务的能力的，所以，我常常好奇那些不懂技术的管理者是如何管理软件研发团队的。 **小小结：**在我个人看来，“分配任务”的能力很能体现一个管理者的能力。他必须有全局观，这样才能知道如何分配，效率才能达到全局最优。他必须有长远眼光，这样才会知道要在长远任务和短期任务之间做平衡（架构师才能在不同的技术方案做出更合理的选择）。 我也发现，鲜有组织会考虑让员工自行选择任务。让员工自行选择任务，我个人总结有以下几点需要注意： 找出信任他的理由：小心（可能）没有能力完成，但是又主动要求接的员工。这种情况，不是说不好，而是一定要和他共同制定方案，确定阶段性里程碑。这样，你才有信任他的理由。 检验他的方案：让主动的员工在所有人面前或者和你一对一地阐述自己的解决方案 小结 以上是卓越管理的两条技巧。看似简单，其实不易。比如在有些组织，根本上就没有“分享的基因”，你谈指导，得到的只是不理解。而且，面对中国的国情（面子、关系……），你需要权衡各方的“面子”和权力，更不易。大家且行且珍惜。 我个人作为一个组织的设计者来看这些“技巧”是有原因的。因为我觉得很多问题，并不是个人问题，而是组织设计的问题。

申明：缩短出活时长的目的不是为了让他们有更多时间加班。目的是提高团队的生产力。这样我们才有更多时间陪家人。 作为一个管理者，一定会遇到的一个问题是：如何团队新人更快的“出活”？ 面对这样的问题，行业内，我见过不少管理者，就直接丢给他一堆源码和文档，就什么也不管了。直到一个星期后才询问新人理解了多少，或者直接丢给他一个需求让他去实现。 这样做意味着： 一个星期是出不了活的，因为你已经在一个星期后才给他任务 一个星期后，你敢100%保证他所理解的东西能帮忙到他完成你一个星期后给他的需求？很有可能，他所做的需求和这一个星期内看的东西毫无关系 那怎么办呢？我知道你心中开始疑问。接下来，我介绍一些我个人的看法和做法。 “让新人更快的出活”是一个目标状态，我们应该问的是：达到这个目标状态的前提条件是什么？ 只要保证了这个前提条件，就船到桥头自然直。 我总结的前提条件有： 条件1. 对业务有基本的认识。比如做家电IoT时，他必须亲自拿着手机尽可能的玩一遍所有的家电。 条件2. 对于整个系统架构有一个大体的思考框架。比如家电IoT的整体架构有一个Big picture。 条件3. 大概了解每个团队成员的职责，知道哪类问题该找谁。 条件4. 了解自己的职责所在。这样才能有的放矢，至少，知道自己应该重点看哪些文档。 要达到这些前提条件的做法是什么呢？ 关于条件1：对业务有基本的认识 举例来说就是让他拿着一个家电说明书，然后让家电连上网，再控制他。这个过程，我们如何验证他的学习效果呢？ 让他记录下使用产品这个过程的困惑，因为这些困惑就是真正用户的困惑。换句话，除了让新人了解了业务，还能帮助我们这些“资深用户”找出产品所存在的问题。 关于条件2：对于整个系统架构有一个大体的思考框架 让团队里最熟悉整个系统架构的人，给这些新人讲解。让新人有一个全局观。同时，这个过程，也是让新人有发现系统构架存在的问题的机会。如何验证新人的学习效果呢？ 让新人当着所有人的面新口说一遍整个系统架构，并在白板上画出来。当然，如果所在团队没有这样的条件，就让他给另一个团队成员讲，也是可以的。 条件3：大概了解每个团队成员的职责，知道哪类问题该找谁 为每个新人分配到一个“辅导员”的同事。这个辅导员有责任回答新人所有问题。 这样做，有几个好处： 对新人有更多的人文关怀。特别是对于一个第一次来公司所在城市的外地人员。 新人可更快融入团队。因为这样新人就不会觉得“怯场”。也可以让新人更快的了解团队的文化。 作为团队的“老人”，也能更深入的了解这位新人。最终达到团队match的状态。 这点，我所经历的ThoughtWorkers就做得非常好。 条件4：了解自己的职责所在 当了解系统的整体架构后，我们只要画出他的职责的那块，他就可以很快地理解了。也就知道他接下来要做什么了。 再说了，我们的辅导员也有责任让他知道他接下来要做什么。 让新人更快出活的小技巧 以下是我自己总结的一些小技巧。 让新人和老人结对编程。比如让老人完整的实现一个需求，新人就坐在旁边看。这样，新人就很快熟悉在当前团队中一个完整的开发流程是怎样的了。 让新人去测试老人实现的需求。比如老人实现了一个需求，也自测了。但是我们团队有一个要求，只有别人测试过了，才算测试通过。在测试人员不足时，可以这么做。 让新人做测试即可以让他更快的熟悉业务，又可以培养他的测试思维。 小结 一个新人要多快出活，除了新人本身的素质外，我们作为管理者需要不断地思考，如何缩短他们的出活时长。 再次申明：缩短出活时长的目的不是为了让他们有更多时间加班。目的是提高团队的生产力。这样我们才有更多时间陪家人。 图源：https://www.pexels.com/photo/clown-fish-swimming-128756/