first commit

专栏/赵成的运维体系管理课/18持续交付流水线软件构建难吗？有哪些关键问题？.md

@@ -0,0 +1,108 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            18 持续交付流水线软件构建难吗？有哪些关键问题？
+                            上期文章我们介绍了需求分解与应用对应的管理方式，以及提交环节的开发协作模式，今天我们详细介绍一下提交阶段的构建环节，也就是我们经常提到的代码的编译打包。
+
+构建环节
+
+由于静态语言从过程上要比动态语言复杂一些，代码提交后，对于Java和C++这样的静态语言，我们要进行代码编译和打包。而对于PHP和Python这样的动态语言，就不需要编译，直接打包即可。
+
+同时，编译过程就开始要依赖多环境以及多环境下的配置管理，并根据不同的环境获取不同的配置，然后打包到最终的软件发布包中。
+
+下面我就结合自己的实践经验，以Java为例，对构建环节做下介绍。
+
+构建过程中我们要用到以下4种工具：
+
+
+Gitlab，代码管理工具，也是版本管理工具；
+Maven，依赖管理和自动化构建工具，业界同类型的工具还有Gradle等；
+Docker，用来提供一个干净独立的编译环境；
+自动化脚本和平台，自动化构建的任务我们使用Python脚本来实现代码获取、编译执行、软件包生成等。
+
+
+具体整个构建过程图示如下：
+
+
+
+我们以Java为例描述如下。
+
+1.首先准备好JDK的编译镜像，这个镜像环境与线上运行环境保持一致，比如OS版本、内核参数以及JDK版本等基础环境。当需要启动一个构建任务时，就创建一个对应的Docker实例，作为独立的编译环境。
+
+2.构建任务会根据应用配置管理中的Git地址，将代码克隆下来放到指定的编译目录。Docker实例启动后，将编译目录挂载到Docker实例中。
+
+3.执行mvn package命令进行编译打包，最终会生成一个可发布war的软件包。同样的，对于C++、Go、Node.js，也会准备好类似的编译镜像。不同的是，打包时，对于C++中的cmake和make，Go中的go install等等，最终也会生成一个可发布的软件包。
+
+4.构建完成后，生成软件包放到指定构件库目录，或者直接发布到maven的构件库中管理，然后将Docker实例销毁。
+
+上述就是一个完整的构建过程。在这里，你一定会有一些疑问，那么，我先回答几个比较常见的问题，欢迎你留言和我继续讨论。
+
+几个关键问题
+
+1.配置文件如何打包？
+
+这个问题，我们在前面持续交付的多环境配置管理文章中，已经详细介绍过。这里我们结合构建过程，再介绍一下。
+
+在上述第3个步骤中，我们要进行代码编译。按照持续交付理念，软件只需打包一次就可以各处运行，这对于代码编译是没有问题的，但是对于一些跟环境相关的配置就无法满足。
+
+比如，我们前面讲到，不同的环境会涉及到不同的配置，如DB、缓存。而且，其他公共基础服务在不同环境中也会有不同的地址、域名或其他参数配置。
+
+所以，我们就需要建立环境与配置之间的对应关系，并保存在配置管理平台中，至于如何来做，大家可以参考前面多环境配置管理的文章。
+
+这里我们回到打包过程上来。
+
+在做构建时，我们是可以确认这个软件包是要发布到哪个环境的。比如，按照流程，当前处于线下集成测试环境这个流程环节上，这时只要根据集成测试环境对应的配置项，生成配置文件，然后构建进软件包即可。如果是处于预发环境，那就生成预发环境对应的配置文件。
+
+在我们的实际场景中，多个环境需要多次打包，这与我们持续交付中只构建一次的理念相悖。这并不是有意违背，而是对于Java构建出的交付件，最终无论生成的是war包，还是jar包，上述提到的跟环境相关的配置文件，是要在构建时就打入软件包中的。
+
+而且在后续启动和运行阶段，我们是无法修改已经构建进软件包里的文件及其内容的。这样一来，配置文件无法独立发布，那么就必须跟软件包一起发布。所以，在实际场景下，我们要针对不同环境多次打包。
+
+那么，我们如何确保多次打包的效果能够和“只构建一次”理念的效果相一致呢？
+
+这就还是要依赖我们前面介绍的各个环节的建设过程，主要有以下3个方面：
+
+
+代码提交。通过分支提交管理模式，每次构建都以master为基线，确保合入的代码是以线上运行代码为基础的。且前面的发布分支代码未上线之前，后续分支不允许进入线上发布环节，确保发布分支在多环境下是同一套代码。
+编译环境统一。上述过程已经介绍，编译环境通过全新的Docker容器环境来保证。
+配置管理。前面介绍到的多环境配置管理手段， 通过模板和auto-config的配置管理能力，确保多环境配置项和配置值统一管理。
+
+
+至此，一个完整的软件构建过程就完成了。可以看到，如果充分完善前期的准备工作，在做后期的方案时就会顺畅很多。
+
+2.为什么用Docker做编译环境的工具？
+
+Docker容器很大的一个优势在于其创建和销毁的效率非常高，而且每次新拉起的实例都是全新的，消除了环境共用带来的交叉影响。而且对于并发打包的情况，Docker可以快速创建出多个并行的实例来提供编译环境，所以无论在效率上还是环境隔离上，都有非常好的支持。
+
+你可以尝试一下我的这个建议，确实会非常方便。
+
+3.为什么不直接生成Docker镜像做发布？
+
+在使用Docker容器做编译的过程中，我们最终取得的交付件模式是一个war包，或者是一个jar包，这个也是我们后续发布的对象。
+
+可能有读者会问：为什么不直接生成Docker镜像，后续直接发布镜像？
+
+这确实是一个好问题。如果单纯从发布的维度来看，直接发布镜像会更方便，更高效。不过，在现实场景下，我们应该更全面地看问题。
+
+早期我们曾有一段时间使用OpenStack+Docker的模式进行物理机的虚拟化，以提升资源利用率。这实际上是将容器虚拟机化。
+
+也就是说，虽然Docker是一个容器，但是我们的使用方式仍然是虚拟机模式，要给它配置IP地址，要增加很多常用命令比如top、sar等等，定位问题需要ssh到容器内。
+
+这里一方面是因为基于Docker的运维工具和手段没有跟上，当时也缺少Kubernetes这样优秀的编排工具；另一方面，我们之前所有的运维体系都是基于IP模式建设的，比如监控、发布、稳定性以及服务发现等等，完全容器化的模式是没有办法一步到位的。
+
+所以，这里我们走了个小弯路：容器虚拟机化。那为什么我们不直接使用虚拟机，还能帮我们省去很多为了完善容器功能而做的开发工作？所以一段时间之后，我们还是回归到了KVM虚拟机使用方式上来。
+
+这样也就有了上述我们基于虚拟机，或者更准确地说，是基于IP管理模式下的持续交付体系。
+
+经过这样一个完整的持续交付体系过程后，我们总结出一个规律：
+
+容器也好，虚拟机也罢，这些都是工具，只不过最终交付模式不一样。但是前面我们所讲的不管是标准化、多环境、配置管理等等这些基础工作，无论用不用容器都要去做。而且，容器的高效使用，一定是建立在更加完善和高度标准化的体系之上，否则工具只会是越用越乱。
+
+关于持续交付流水线软件构建方面的内容，我们今天先分享到这里，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/19持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障.md

@@ -0,0 +1,114 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            19 持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障
+                            上期文章我结合自己的实践经验，介绍了持续交付中流水线模式的软件构建，以及在构建过程中的3个关键问题。我们可以看出，流水线的软件构建过程相对精简、独立，只做编译和打包两个动作。
+
+但需要明确的是，在持续交付过程中，我们还要做很多与质量保障相关的工作，比如我们前面提到的各类功能测试和非功能测试。
+
+所以，今天我们聊一聊在流水线构建过程中或构建完成之后，在质量保障和稳定性保障方面，我们还需要做哪些事情。
+
+首先，我们回顾一下之前总结的这张流程图：
+
+
+
+可以看出，在流水线构建过程中，我们尤其要重视以下3个方面的工作内容。
+
+依赖规则限制
+
+主要是对代码依赖的二方包和三方包做一些规则限制。比如，严格限定不允许依赖Snapshot版本；不允许引入有严重漏洞的版本，如Struts2的部分版本；检测JAR包冲突，如我们常用的Netty、Spring相关的包；限定某些软件包的最低版本发布，如内部提供的二方包，以确保版本收敛，降低维护成本。
+
+过滤规则上，通过Maven构建软件包过程中生成的dependency:list文件，将GroupID和ArtifactID作为关键字，与我们设定的版本限制规则进行匹配。
+
+两个示例如下（真实版本信息做了修改）：
+
+检测JAR包冲突：
+
+
+[WARNING] 检测到jar包冲突: io.netty:netty-all, 版本: 4.0.88.Final, 当前使用:
+4.0.22.Final
+
+
+限定最低版本：
+
+
+[WARNING] 检测到 mysql:mysql-connector-java, 版本 5.0.22, 版本不符合要求, 需要大于等于
+5.0.88。旧版存在已知兼容性bug，导致连不上数据库, 请在2018-01-15 00:00:00前升级完成, 否则将被禁止发布，如有疑问，请联系@发布助手
+
+
+JAR包依赖以及维护升级，通常是一件令我们比较头疼的事情，特别是在运行时出现的冲突异常，更是灾难性的。为了从技术角度更好地进行管理，我们需要做好隔离，这一点可以利用JVM类加载机制来实现。
+
+如果你有兴趣，可以在网上参考阿里的潘多拉（Pandora）容器设计资料，这里我们就不作详细介绍了。
+
+功能测试
+
+包括单元测试、接口测试、联调测试和集成测试。这里的每个测试环节起到的作用不同，联调测试和集成测试依赖的主要手段还是手工验证，所以这里我们分享下可以通过自动化手段完成的单元测试和接口测试。
+
+这里主要用到的几个工具：
+
+
+JUnit 和TestNG，分别做单元测试和接口测试；
+Maven插件，maven-surefire-plugin，用来执行JUnit或TestNG用例；
+JaCoCo，分析单元测试和接口测试后的代码覆盖率；
+Jenkins，自动化测试任务执行，报表生成和输出，与Maven、JUnit、GitLab这些工具结合非常好。
+
+
+关于上述这几种工具，我在此就不展开详细介绍了，你可以自行上网查询和学习。
+
+下面，我们分析一下功能测试中的两个重要环节：单元测试和接口测试。
+
+
+单元测试，由开发完成测试用例的开发，对于需要连接DB的用例，可以用DBUnit这样的框架。用例的自动执行，每次代码开发完成，开发执行mvn test在本地进行自测通过，然后提交到GitLab。可以在GitLab中设置hook钩子，和回调地址，提交的时候在commitMsg增加钩子标识，如unitTest，这样提交后就触发回调自动化单元测试用例执行接口，确保提交后的代码是单元测试通过的，最终可以通过JaCoCo工具输出成功率和代码覆盖率情况。
+接口测试，用例编写上使用TestNG，这个测试框架相比JUnit功能更全面，也更灵活一些。但是过程上与单元测试类似，当然也可以不通过hook方式出发，可以通过手工触发进行测试。
+
+
+上述自动化测试环节结束，软件包就可以发布到我们之前说的项目测试环境或集成测试环境进行功能联调和测试了，这时就需要部分人工的介入。
+
+非功能测试
+
+在功能验证的同时，还需要并行进行一些非功能性验证，包括安全审计、性能测试和容量评估 。分别介绍如下：
+
+
+安全审计，由安全团队提供的源代码扫描工具，在构建的同时，对源代码进行安全扫描，支持Java和PHP语言。可以对源代码中的跨站脚本、伪造请求、SQL注入、用户名密码等敏感信息泄露、木马以及各类远程执行等常见漏洞进行识别，对于高危漏洞，一旦发现，是不允许构建出的软件包发布的。而且实际情况是，不审不知道，一审吓一跳，我们前面几次做代码扫描时，各种漏洞触目惊心，但是随着工具的支持和逐步改进，基本已经将这些常见漏洞消灭在萌芽状态。
+
+
+下面是扫描结果的简单示例（目前扫描工具已经开源，请见文末链接）：
+
+
+
+
+性能和容量压测，主要针对核心应用，进行发布前后的性能和容量比对，如果出现性能或容量差异较大，就会终止发布。关于这一点，我在后面稳定性保障的文章中会详细介绍到。这个验证工作，会在预发或Beta环境下进行验证，因为这两个环境是最接近线上真实环境的。
+
+
+下图是一张发布前后的效果比对示意图，正常情况下，性能曲线应该是基本重叠才对，不应该出现较大的偏差。
+
+
+
+最后
+
+到这里，我们稍作一个总结。
+
+关于持续交付中的流水线模式，我们在前面两期文章以及本期的分享中，相对完整地介绍了从需求分解开始，到代码提交、软件构建，再到功能和非功能测试验证的整个过程。这个过程就是我们常说的持续集成。
+
+之所以我没有在一开始引入这个概念，是因为，如果我们将注意力集中到这一过程中具体的动作和问题上，会更有利于我们理解，而不是一开始就被概念性的术语和框架束缚住。
+
+流水线模式功能测试和非功能测试的整个过程可以总结如下：
+
+
+
+同时，我们在上面持续集成的过程中，要基于前面介绍的各类环境和基础配置管理，比如功能验证就需要在线下环境中的开发环境、项目环境以及集成测试环境上进行验收。
+
+而非功能验证的性能和容量评估，就需要在线上环境里的预发或Beta环境中完成。这里就已经涉及到了软件的部署发布。
+
+下一期文章，我将分享线上发布的整个过程，并对整个持续交付体系内容做一个收尾。欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+附：源代码安全审计工具
+https://github.com/wufeifei/cobra
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/20做持续交付概念重要还是场景重要？看笨办法如何找到最佳方案.md

@@ -0,0 +1,112 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            20 做持续交付概念重要还是场景重要？看笨办法如何找到最佳方案
+                            上期文章中我们讲到，在经过严格的依赖规则校验和安全审计之后，构建出的软件包才可以部署发布。
+
+在开发环境、项目环境、集成测试环境以及预发环境下，我们还要进行各类的功能和非功能性测试，最后才能发布到正式的生产环境之上。
+
+通常状况下，做一次软件版本发布，必须经过以下几个环境（如下图所示）。需要明确的是，项目环境和“小蘑菇”（内部叫法）环境，只有特殊版本才会配备，这里我们不做强制。
+
+
+
+上述这些环境我们在之前都介绍过。而历经如此多的环境，高效的自动化持续部署和发布就变得尤为重要。
+
+特别是最后的线上发布环节，还需要确保业务连续稳定、无间断，所以，在复杂的微服务架构环境下，我们对软件的发布策略选择、自动化程度和稳定性要求就更高了。
+
+今天，我们一起看看整个流水线软件部署和发布的细节。
+
+软件的持续部署发布
+
+这里，我们直接以生产环境的发布过程来讲解。软件的部署发布，简单来说就是：
+
+将构建完成和验证通过的应用软件包，发布到该应用对应环境下的IP主机上的指定目录下，并通过应用优雅上下线，来实现软件最新版本对外提供服务的过程。
+
+这个过程会包含的环节，我以图示整理如下：
+
+
+
+我们可以看到，软件部署发布，听上去就是把软件部署一下，然后启动起来。这样的操作方式对于单体架构软件没有问题，但是在微服务架构下就满足不了要求了。
+
+单体架构软件启动起来就可以提供服务，但是对于微服务应用，无论停止还是启动，都需要考虑到对周边其它依赖和被依赖应用的影响才可以，考虑的点也就相对较多。
+
+我们针对单机发布，分环节来看一下：
+
+
+从CMDB中，拿到线上生产环境下的应用主机IP列表去对应关系，目的是要将软件包发布到应用对应的IP主机上。
+
+检查每台机器上的服务是否正常运行，如果是正常服务的，说明可以发布，但是服务本身异常，就要记录或跳过。
+
+下载war包到指定目录。这里要依赖前期我们介绍的应用配置管理，在这一步要获取到该应用的源代码目录。
+
+关闭该应用在这台主机上的监控，以免服务下线和应用终止产生线上错误告警。
+
+优雅下线。RPC服务从软负载下线，如果该应用还提供了http的Web调用，就需要从Nginx这样的七层负载下线，下线动作均通过API接口调用方式实现。
+
+下线后经过短暂静默，重启应用。对于Java应用来说，重启时可以自动解压，启停命令等还是之前从应用配置管理中获取响应路径和命令脚本名称。
+
+优雅上线，进行健康监测，检查进程和应用状态是否正常，如果全部监测通过，则开始上线服务，开启监控。
+
+
+上述是一个应用的单机发布过程，过程比较长，但是可以看出，每个环节并不复杂。这里我们需要注意两个关键点：
+
+
+针对场景，进行细分，这样就可以化整为零，把一个乍看上去很复杂的过程，分解成一个个可执行的步骤。
+与服务化的软负载和注册中心进行交互，确保应用是可以优雅上下线的，而不是简单粗暴地启动和停止。
+
+
+发布策略
+
+上述过程是针对单机的操作步骤。但是，如果我们有上百台主机，甚至一些大的集群有上千台主机，这时应该怎么发布呢？这里就涉及到发布策略问题。
+
+业界常见的几种模式，如蓝绿发布、灰度发布（金丝雀发布）、滚动发布等等，这几种模式网上资料丰富，在这里我们就不逐一展开详细介绍了。
+
+这里，我们主要以灰度发布和滚动发布的组合方式为例，详细分析一下这种发布模式。
+
+前面介绍的线上Beta环境，选择的就是金丝雀发布模式，我们内部称之为灰度发布或Beta发布。后来国外Netflix持续交付经验传播比较广，所以我们经常可以听到金丝雀发布这种方式，而其本质上还是灰度发布模式。
+
+Beta环境下，我们会保留1-2台应用主机，引入较少的线上真实用户流量。发布到这个环境上时，对于核心应用和大规模的集群，我们会静默较长时间，以观察应用的新版本运行状态。
+
+如果没有严重的报错或崩溃，静默期过后，我们认为软件质量和稳定性是没有问题的，接下来就会发布到正式的生产环境上。
+
+因为生产环境上大的集群可能会有上百台甚至上千台主机，如果每台主机逐一单独发布，这样会导致发布效率过低；但是一次性发布数量太多，又会对线上应用容量大幅度缩减，极有可能会导致服务雪崩或业务中断。
+
+所以我们选择的方式就是滚动发布，或者可以理解为分批次发布：即每批次发布10台或20台，升级完成后，再启动下一批次发布。这样每次发布的机器数量可以自行设定，但是必须低于50%。
+
+至此，一个应用的滚动发布流程就结束了。根据我们实践的具体情况，这种灰度加滚动的发布模式，相对平稳和可控。相比于蓝绿发布，不需要额外再独立一个环境出来，且不需要每次发布都要做一次整体的流量切换，避免产生较大的操作风险。
+
+对于回滚，我们会根据上个版本的war包名称记录，在发布过程中或发布后出现严重情况时，直接快速回滚。因为这个操作是在紧急和极端的情况下才执行，所以提供一键操作，过程跟上述的发布过程相似，在此也不再赘述。
+
+持续交付体系的收益
+
+持续交付体系运作起来后，整个流水线过程完全自助发布，运维无需介入，达到了DevOps，或者说是NoOps的效果。如下图所示：
+
+
+
+总结
+
+至此，我们整个持续交付体系的内容就全部介绍完了。对于整个过程的总结，你可以参考本专栏“持续交付”主题的第一篇文章[《持续交付知易行难，想做成这事你要理解这几个关键点》]，我在文中对整个持续交付体系进行了比较完整的梳理。
+
+细心的你应该可以发现，到本期文章为止，我并没有提到太多DevOps相关的内容，而这个恰恰是当前业界非常火热的概念。在写作过程中，我也没有特别强调持续交付是什么，持续集成是什么，而这些又是当前DevOps里面特别强调的部分。
+
+我之所以这样做是因为，概念都是一个个名词或者Buzzword（时髦名词），它们所表达的意思也都非常泛，每个人，每个团队或每个组织对它们的理解以及解读都是不一样的。
+
+就拿DevOps举例，有谁能说清楚它到底是什么，到底代表什么意思？估计一千个人会有一千种理解，不同的团队对它的实践模式也不一样。
+
+所以，如果直接从概念出发，反而容易让我们迷失方向，忘记想要解决的问题，让我们脱离所处的实际场景，把精力都放在了各种所谓的工具和技术上。这一点也恰恰与我所一直强调的，要从实际问题和业务场景出发来考虑解决方案相违背。
+
+在我们“持续交付”主题的分享中，你可以看到，有很多的解决方案并没有标准化的模式，也没有哪一个工具或技术能够直接解决这些问题。
+
+我们所采取的手段，其实都是些笨办法：即找到问题，分析问题，调研解决方案，讨论碰撞，然后慢慢摸索和实践，找出最合适我们的方式。
+
+希望我的分享能够给你带来启发，就像我们开篇词提到的：思路上的转变远比技术上的提升更为重要。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/21极端业务场景下，我们应该如何做好稳定性保障？.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            21 极端业务场景下，我们应该如何做好稳定性保障？
+                            从今天开始，和你分享我对微服务和分布式架构下的稳定性保障的理解。
+
+稳定性保障需要一定的架构设计能力，又是微服务架构比较核心的部分。在陈皓老师的“左耳听风”专栏，以及杨波老师的“微服务架构核心20讲”专栏都有非常详细的介绍。所以在我的专栏里，我会结合特定的场景，并着重从运维和技术运营的角度来分享。
+
+我们所面对的极端业务场景
+
+首先，看一下我们当前所面对的极端业务场景，我把它大致分为两类。
+
+1.可预测性场景
+
+什么是可预测性？简单来说，就像电商每年的大促，如618、双11、双12等等。这类业务场景是可预测的，业务峰值和系统压力峰值会出现在某几个固定的时间点，我们所做的所有准备工作和稳定性应对措施，都是针对这些固定时间点的，比如零点时刻。
+
+峰值压力可预测，就意味着可以提前评估用户访问模型，并根据模型进行压测调优。发现系统中的瓶颈就调优或者扩容，调整完成之后，继续压测，继续调整，直至系统容量达到原来设定的目标。由此可见，在可预测的场景下，与后面的不可预测场景相对比，从准备过程上来说会更加从容。
+
+但是，我们的优化或扩容是有限度的，也就是不会无限度地投入成本，来满足零点这个峰值时刻，让所有用户都能够正常访问。从成本和收益角度来说，这样做是不现实的。
+
+所以，在峰值那个时间点上，当用户流量远远大于系统容量时，我们所采取的措施绝不是再去扩容或优化，因为无论是从时效性、系统稳定性还是成本收益上看，这样做都已经无法满足要求了。
+
+那我们该采取什么策略呢？这里我们采取的策略是在系统承诺容量内，保证系统的核心功能能够正常运行。以电商为例，就是要确保整个交易链路是正常的，用户可以正常登陆，访问商品，下单并最终支付。对于非核心功能，就会通过预案执行功能降级。对于超出系统承诺容量的部分进行流量限流，并确保在某些异常状况下能够熔断或旁路，比如缓存故障，就要马上限流并将请求降级到数据库上。
+
+所以，我们在618，双11和双12的零点峰值时刻去访问各大电商网站，很大概率上都会提示系统正忙，请稍后再试，短则2~3分钟，长则5~10分钟，再去访问，网站功能就一切正常了。这并不代表各大电商网站宕机了，而是其在瞬时超大流量访问压力下采取的一种保护措施，这一点反而说明这些电商网站的大促预案非常完善。
+
+2.不可预测性场景
+
+我刚刚提到的电商大促场景，其实已经非常复杂了，没有一定的整体技术能力，想做好从容应对也并非易事。我们这两年做大促模拟压测，动辄上百号人通宵投入，说到底还是在这方面的经验以及各类工具平台的积累不够，体系的完善需要一定的周期和过程。
+
+那不可预测的场景就更为复杂。社交类业务就具有这种明显的特征，比如微博、朋友圈、空间等等。以微博为例，我们知道之前鹿晗公布恋情，王宝强以及乔任梁等的突发事件等等，这些事情什么时候发生，对于平台来说事先可能完全不知道，而且极有可能是大V的即兴发挥。当然，现在因为商业合作上的原因，某些大V的部分营销活动也会与各类社交业务平台提前沟通，确保活动正常执行，但是即使是提前沟通，周期也会非常短。
+
+对于不可预测性的场景，因为不知道什么时候会出现突发热点事件，所以就无法像电商大促一样提前做好准备。社交类业务没法提前准备，就只能随时准备着，我认为这个挑战还是非常大的。
+
+我们要迎接的技术挑战
+
+说完了场景，我们来看看这给技术带来了哪些挑战。
+
+1.运维自动化
+
+这个不难理解，应对极端场景下的系统压力，一定要有资源支持，但是如何才能将这些资源快速扩容上去，以提供业务服务，这一点是需要深入思考的。结合前面我们讲过的内容，标准化覆盖面是否足够广泛，应用体系是否完善，持续交付流水线是否高效，云上资源获得是否足够迅速，这些都是运维自动化的基础。特别是对于不可预测的场景，考验的就是自动化的程度。
+
+2.容量评估和压测
+
+我们要时刻对系统容量水位做到心中有数，特别是核心链路，比如电商的交易支付链路。我们只有对系统容量十分清楚，才能针对特定场景判断出哪些应用和部件需要扩容，扩容多少，扩容顺序如何。同时，系统容量的获取，需要有比较完善的自动化压测系统，针对单接口、单应用、单链路以及全链路进行日常和极端场景下的模拟压测。
+
+3.限流降级
+
+我们前面提到了电商大促的例子，业务在峰值时刻，系统是无论如何也抵御不住全部流量的。这个时候，我们要做的就是保证在承诺容量范围内，系统可用；对于超出容量的请求进行限流，请用户耐心等待一下。如何判断是否需要限流呢？这时我们要看系统的各项指标，常见的指标有CPU、Load、QPS、连接数等等。
+
+同时，对于非核心的功能，在峰值时刻进行降级，以降低系统压力。这里有两种方式，分别是主动降级和被动降级。主动降级就是在峰值时刻，主动把功能关掉，如商品评论和推荐功能等等；我们前面介绍到的静态化，也是一种降级策略。对于被动降级，也就是我们常听到的熔断。某个应用或部件故障，我们要有手段将故障隔离，同时又能够保证业务可用，所以会涉及故障判断和各类流量调度策略。
+
+4.开关预案
+
+上面介绍到的限流降级，也是一类开关，属于业务功能开关；还有一类是系统功能开关，比如当缓存故障时，我们就需要将请求转发到数据库上，目的也只有一个，让系统可用。但是问题来了，数据库的访问效率没有缓存高，所以缓存可以支撑的流量，数据库肯定是支撑不了的，怎么办呢？这时，就要与限流策略结合起来，先限流，限到数据库能够支撑的容量，再做降级。这样几个策略组合在一起，就是应急预案的执行了。当然，预案里面还会有业务预案。
+
+5.故障模拟
+
+上述预案，需要在日常，甚至是从经历过的故障中提炼出场景，制定好策略，然后不断进行模拟演练。只有这样，等到真正出现问题时，我们的预案才可以高效执行。我们知道Netflix的Chaos Engineering，其中的Chaos Monkey，就是专门搞线上破坏，模拟各种故障场景，以此来看各种预案执行是否到位，是否还有可以改进的地方。
+
+所以，类似Chaos Engineering的故障模拟系统，也需要建设起来。我们需要模拟出一些场景，比如最常见的CPU异常，RT响应异常，QPS异常等等，看我们的预案是否能够快速执行，能够保持系统或将系统快速恢复到正常状态。
+
+6.监控体系
+
+最后，我再提一下监控。通过我们前面介绍的内容，监控的重要性就不言而喻了，因为所有的指标采集和统计，异常判断，都需要监控体系的支持。监控体系和前面介绍的运维自动化一样，都是最为基础的支撑平台。
+
+极端业务场景下的不确定因素
+
+上面我们讨论了极端业务场景给技术层面带来的挑战。但是对于稳定性保障而言，我认为最困难的部分，不在技术层面，而是在业务层面，也就是用户的业务访问模型。从技术层面来说，我们还有一些确定的套路可以去遵循，但是访问模型就是个极不确定的因素了。
+
+我们这里还是以电商来举例说明，比如大促时用户下单这个逻辑。一个用户在购物车勾选商品去结算这个场景，用户的访问模型或业务场景就可能会有很多变化，比如是下1个商品的订单，还是同时5个商品的订单？每个商品的购买数量是1个、2个还是3个？商品的购买数量有没有限制？这些商品涉及1个卖家，还是多个卖家？不同卖家又会有不同的优惠折扣，是买二送一，还是满100送20？满一定额度之后是否包邮？全站促销是否有全站优惠，是否有时间段限制？优惠之间是否有优先级和互斥逻辑？支付方式是优先使用支付宝，还是微信，亦或是银行卡等等。
+
+上面这些还只是简单描述，并且是针对单个用户的。当用户数量达到几十万，上百万之后，用户行为可能还有访问首页、详情页以及搜索的情况等等，场景更复杂，整个业务模型中的变量因素就会非常多，且不确定。
+
+往往某个因素的变化，就可能带来容量模型的改变。假设1个商品，1个卖家，1个优惠策略，对DB产生的QPS是20，TPS是10，但是这其中的因素稍微一变化，产生的QPS和TPS就是翻倍的。如果这一点评估不到位，大促时实际的用户场景跟预估的偏差过大，系统可能就会挂掉。
+
+所以，对于稳定性而言，用户访问模型才是关键，这个摸不准，只有技术是没用的，这就更需要我们能够深入业务，理解业务。
+
+我们经常听到的“脱离业务谈架构，谈技术，都是不负责任的”，原因就在于此。希望今天的内容能够让你在学习到知识和技能的同时，也有所启发，切忌脱离业务，空谈技术。
+
+今天我们分享了极端业务场景下，如何做好稳定性保障。关于稳定性保障，你还有哪些问题？有过怎样的经验？欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/22稳定性实践：容量规划之业务场景分析.md

@@ -0,0 +1,63 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            22 稳定性实践：容量规划之业务场景分析
+                            上期文章我们从整体上介绍了极端业务场景下，如何做好稳定性保障工作。今天，我们结合电商大促这个场景，来看一下容量规划这项工作。
+
+稳定性保障的一个难点是我们要面对一个非常复杂的因素，那就是业务模型，或者叫用户访问模型。因为它的不确定性，会衍生出很多不同的业务场景，而不同的场景，就会导致我们的应对策略有所不同。
+
+所以，容量规划，就是对复杂业务场景的分析，通过一定的技术手段（如压力测试），来达到对资源合理扩容、有效规划的过程。
+
+容量规划的场景分析
+
+我们一直在讲，不能脱离业务场景空谈技术，所以我们还是先从电商大促这个业务场景入手来分析。
+
+对于电商来说，核心链路就是交易链路。简单来说，就是用户要能登录，然后能通过浏览商品详情页下单订购，或者加购物车，通过购物车进行订购结算，这个过程中还要进行各种优惠的批价处理，库存的判断等等，形成订购之后，最终还要能够支付成功，一个完整的交易支付流程才算走完。
+
+在大促的峰值时刻，场景可能又有不同，因为绝大部分用户选购什么商品，早已加入到了购物车中，且各种优惠券也已经申领成功，就等着最后这个时间点直接下单完成订购。所以，在大促这个场景下，交易下单这个环节是核心中的核心。
+
+因为这个时间点的交易流量实在是太高了，所以近两年电商也改变了一些玩法，其目的就是希望减少峰值流量，让流量在整个大促阶段更加均匀。具体的运营和玩法细节这里就不详细介绍了。
+
+那么，我们要应对的场景就相对清晰了，就是在大促零点峰值时刻，评估好交易流量，再进一步转化一下，就是每秒的交易订单峰值。
+
+下图就是我们进行评估的路径分析示例，用户首先从首页、大促会场或者微信里的分享页面转化过来，然后通过搜索、店铺、详情页以及购物车进行最后的转化，形成订购下单和最终的支付。
+
+
+
+具体数值的评估上，我们会跟产品运营团队共同讨论，整体的业务目标由运营团队给出，比如GMV目标收入，UV、PV、转化率、客单价以及商品单价，这些都是业务目标。通过这些业务数据，我们根据上图的路径逐步分解，就会逐步得出每一层的流量数据。
+
+假设大促会场会有500万UV，根据GMV和客单价，如果要完成目标，推导出到详情页的转化率需要达到60%（产品运营需要努力达成这个业务目标），那详情页的UV就是300万；根据用户访问行为分析，对详情页的各个应用产生的QPS再做一个评估，这样单个应用的容量值就有了，然后再进一步向下转化，能够形成订购，形成加购物车的又有多少，再进行评估，最后就可以得出一个交易下单的峰值以及支付的峰值。
+
+计算出峰值后，还要与历年评估的峰值数据，以及实际的峰值数据进行对比，根据对比情况进行调整。评估出来的这个峰值，就是系统要承诺支撑的容量，因为只有达到这个容量值，才能支撑业务完成对应的业务目标。
+
+总结来说，这就是一个根据业务GMV、UV等目标，对技术上的交易下单峰值这个核心指标进行推导的过程。
+
+那么，接下来就根据评估的各个应用和基础服务需要承担的流量，先扩容一轮，同时开始构造数据模型和压测模型来模拟真实流量，以此验证我们的系统是否能够达标，过程中再进行局部的扩容和优化。
+
+一般来说，先进行单链路压测，比如购物车订购，详情页订购等场景的压测，达标后再进行多链路压测，最后再进行全链路压测，直至达成目标。为了能够保有一定的容量缓冲，最后几轮压测，我们会将压测流量调整到目标值的120%或150%，来保证系统能够应对足够极端的场景，这样才能够游刃有余地实现100%的目标。
+
+构造压测的数据模型
+
+如何构造压测的数据模型呢？这是一个比较复杂的问题，因为我们靠拍脑袋或者靠猜，是无法准确评估的。通常情况下，我们从以下两方面入手。
+
+一方面，数据模型要接近真实场景。这就需要我们不断地积累经验，记录早期大促的详细数据和真实场景（比如不同用户购物车里的商品数量、优惠策略、不同渠道比例等，以及各种运营活动的玩法），这样可以最大程度地模拟真实的用户访问模型。这个过程，蘑菇街更多的还是手工推导，像阿里做得比较极致，可以通过BI系统，将往年模型和当年模型进行分析比对，直接生成对应的数据模型，甚至是多套模型。
+
+另一方面，数据量要接近真实场景。数据量有很多维度，比如用户数量、商品数量、店铺数量、优惠券数量等等。这里一般会通过数据工厂这样的工具平台，结合运营团队给出的数据量评估，快速制造出对应量级的数据。另一种方式就是从线上将真实数据，进行敏感信息脱敏处理后，导出到另一张影子表中，专门提供给压测使用，这样做的好处是不会污染线上运行数据。
+
+总结
+
+通过上面的分享，我们应该不难发现，容量规划工作，单纯靠技术能力是无法解决的，需要经验和数据的积累，到了阿里这个体量就必须借助人工智能和各类分析算法这样更高级的手段才能解决。
+
+同时，容量问题，也不是简简单单通过资源扩容这种成本投入就可以解决的，扩容是最后的执行手段，但是怎么合理的、科学的扩容，就需要有合理的规划。当业务体量和复杂度到达一定程度时，就要依靠技术人员对业务的深入理解。能够合理规划业务、技术和数据模型，是需要一些经验积累，以及在各类极端场景下的经历。
+
+最后，如此复杂的技术体系，也只有在同样复杂的场景下才会被催生出来，才会有存在意义。所以，我们在学习借鉴时，还是要从各自的实际场景出发，慢慢积累，大可不必强求短期速成。
+
+你自己是否有过容量规划的经历？遇到过哪些问题？欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/23稳定性实践：容量规划之压测系统建设.md

@@ -0,0 +1,95 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            23 稳定性实践：容量规划之压测系统建设
+                            容量规划离不开对业务场景的分析，分析出场景后，就要对这些场景进行模拟，也就是容量的压力测试，用来真实地验证系统容量和性能是否可以满足极端业务场景下的要求。同时，在这个过程中还要对容量不断进行扩缩容调整，以及系统的性能优化。
+
+今天，我们就来看压力测试的技术实现方式：压力测试系统的建设。我们详细讲讲压力测试的几个维度。
+
+第一个维度，压测粒度
+
+压测粒度上，我们一般会遵照从小到大的规律来做。
+
+1.单机单应用压力测试
+
+优先摸清单个应用的访问模型是怎样的，再根据模型进行单机单应用压力测试。这时我们就可以拿到单个应用和单个应用集群的容量水位，这个值就是后续我们根据业务模型分析之后扩容的基础。
+
+2.单链路压力测试
+
+获取到单个应用集群的容量水位之后，就要开始对某些核心链路进行单独的压力测试，比如商品详情浏览链路、加购物车链路、订购下单链路等等。如下图的交易下单链路压测模型示例，连线上的数字是不同应用或接口调用的流量占比。
+
+
+
+3.多链路/全链路压力测试
+
+当单链路的压测都达标之后，我们就会组织多链路，或者全链路压测。多链路本质上就是多个单链路的组合，全链路就是多链路的组合。如下图就是多个交易场景的多链路组合。
+
+
+
+第二个维度，压测接口及流量构造方式
+
+接口一般分为HTTP接口和RPC接口，这一点应该不难理解，就不做过多讲解了。
+
+流量构造方式上，根据压测粒度的不同，会采用不同的方式，我们常见的有以下几种方案。
+
+1.线上流量回放
+
+这种方式直接利用了线上流量模型，比较接近真实业务场景，常见的技术手段如TCPCopy，或者Tcpdump抓包保存线上请求流量。但是这种方式也存在一些代价，比如需要镜像请求流量，当线上流量非常大的时候就很难全部镜像下来，而且还需要大量额外的机器来保存流量镜像。到了回放阶段，还需要一些自动化的工具来支持，还要解决各种session问题，真正实施的时候，还是会有不少的工作量。
+
+2.线上流量引流
+
+既然线上回放比较麻烦，那为什么不直接使用线上流量进行压测呢？这个思路确实是可行的，我们前面讲过，压测的主要是HTTP和RPC两种类型的接口，为了保证单个应用的流量压力足够大，这里可以采取两种模式。
+
+一个是将应用集群中的流量逐步引流到一台主机上，直到达到其容量阈值；另一个方案是，可以通过修改负载均衡中某台主机的权重，将更多的流量直接打到某台主机上，直到达到其容量阈值。
+
+这个过程中，我们可以设定单台主机的CPU、Load或者QPS、RT等阈值指标，当指标超出正常阈值后就自动终止压测，这样就可以获取到初步的容量值。
+
+这种方式的好处是，不需要额外的流量模拟，直接使用最真实的线上流量，操作方便，且更加真实。下图是两种引流的方案示例。
+
+
+
+3.流量模拟
+
+上述两种流量模拟方式，更适合日常单机单应用的容量压测和规划，但是对于大促这种极端业务场景，真实流量就很难模拟了，因为这种场景只有特定时刻才会有，我们在日常是无法通过线上流量构造出来的。
+
+所以这里就需要利用数据工厂，最终通过流量平台来形成压测流量。这里的工具用到了Gatling，是一款开源的压测工具，用Scala开发的，后来我们针对自己的需求，比如自动生成压测脚本等，做了一些二次开发。
+
+
+
+如果会有多种流量模型的话，就要生成多个流量模型，具体可见下图：
+
+
+
+第三个维度，施压方式
+
+上面介绍了容量压测的构造过程，那接下来我们要做的就是对真实的线上系统施加压力流量了。很自然的，这里就需要有施加压力的机器，在上面“全链路压测系统”那张图中，你可以看到，我们的施压方式是通过上百台的机器根据压测脚本和压测数据对系统施压的，我来简单介绍一下大致过程。
+
+
+通过实现在Web控制台配置好的压测场景，自动生成压测脚本。
+利用数据工厂构造出压测数据，这个就是业务场景的模拟，像阿里做得比较完善，就可以借助AI和BI的技术手段生成很多压测模型，且基本都接近于现实情况下的业务场景。
+通过Web控制台，根据压测脚本和压测数据，生成压测任务，推送到压测集群的Master节点，再通过Master节点推动到上百台的Slave节点，然后就开始向线上系统施加模拟的流量压力了。
+
+
+关于施压机的分布，大部分仍然是跟线上系统在同机房内，少量会在公有云节点上。但是对于阿里，因为其自身的CDN节点遍布全球，所以他就可以将全球（主要是国内）的CDN节点作为施压机，更加真实地模拟真实用户从全球节点进入的真实访问流量。这种方式对于蘑菇街就显得成本过高，技术条件和细节也还达不到这个程度。
+
+当前阿里已经将这种压测能力输出到了阿里云之上，可以说是对其云生态能力的有力补充，同时也为中小企业在容量规划和性能压测方面提供了很好的支持。
+
+第四个维度，数据读写
+
+压测过程中，对于读的流量更好构造，因为读请求本身不会对线上数据造成任何变更，但是对于写流量就完全不一样了，如果处理不好，会对线上数据造成污染，对商家和用户造成资损。
+
+所以，对于写流量就要特殊处理，这块也有比较通用的解决方案，就是对压测的写请求做专门的标记。当请求要写数据库时，由分布式数据库的中间件框架中的逻辑来判断这个请求是否是压测请求，如果是压测写请求则路由到对应的影子库中，而不是直接写到线上正式的库中。
+
+在这之前，要提前创建好对应的影子库。假设建立影子库的原则是原schema + mirro，如果正式库是order，则影子库为order_mirror，这时两个库中的数据量必须是一致的。对于非敏感信息，数据内容也可以保持一致，这样可以在最大程度上保证数据模型一致。
+
+这里再呼应一下我们最开始提到的基础服务标准化工作，如果这个工作在前面做得扎实，它的优势在这里就体现出来了。我们刚刚提到的影子库的路由策略是基于中间件框架来实现的，如果使用的框架不一样，不是标准的，这个功能可能就很难应用起来。这一点在后面全链路以及开关等稳定性方案中，还会涉及到。
+
+今天我们介绍了容量压测的技术方案，比较复杂，而且需要对相应场景进行针对性的建设。关于细节部分，你还有什么问题，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/24稳定性实践：限流降级.md

@@ -0,0 +1,103 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            24 稳定性实践：限流降级
+                            本周我们继续来讨论稳定性实践的内容。在现实情况下，当面对极端的业务场景时，瞬时的业务流量会带来大大超出系统真实容量的压力。
+
+为了应对，前面我们介绍了容量规划方面的实践经验。不过，我们不会无限度地通过扩容资源来提升容量，因为无论从技术角度，还是从成本投入角度，这样做都是不划算的，也是不现实的。
+
+所以，我们通常采取的策略就是限流降级，以保障承诺容量下的系统稳定；同时还有业务层面的开关预案执行，峰值时刻只保障核心业务功能，非核心业务功能就关闭。
+
+今天我们就先来介绍一下限流降级的解决方案。
+
+什么是限流和降级
+
+首先，我们先梳理清楚限流和降级的概念，明白它们会发挥怎样的作用，这样才便于我们理解后续的解决方案。
+
+
+限流，它的作用是根据某个应用或基础部件的某些核心指标，如QPS或并发线程数，来决定是否将后续的请求进行拦截。比如我们设定1秒QPS阈值为200，如果某一秒的QPS为210，那超出的10个请求就会被拦截掉，直接返回约定的错误码或提示页面。
+降级，它的作用是通过判断某个应用或组件的服务状态是否正常，来决定是否继续提供服务。以RT举例，我们根据经验，一个应用的RT在50ms以内，可以正常提供服务，一旦超过50ms，可能就会导致周边依赖的报错或超时。所以，这时我们就要设定一个策略，如果应用的RT在某段时间内超过50ms的调用次数多于N次，那该应用或该应用的某个实例就必须降级，不再对外提供服务，可以在静默一定时间后（比如5s或10s）重新开启服务。
+
+
+这里再特别说一下降级，今天我们讲的内容可以理解为服务降级，后面我会介绍业务开关，可以理解为业务降级。这里只是叫法不同，不同的人有不同的理解，所以我们在讨论概念时，还是尽量回到我们要解决的问题和场景上来，上下文保持一致了，在观点和思路上也更容易达成一致。
+
+讲到这里，再提个问题，我们讲的降级，和熔断这个概念是什么关系？你不妨停下来，按照我们刚刚讲过的思路思考一下。
+
+常见的限流解决方案
+
+我们先看几种常见的限流类型。
+
+第一类，接入层限流。
+
+作为业务流量的入口，我们限流的第一道关卡往往会设置在这里，而且接入层限流往往也是最有效的。这里又有两类解决方案，根据接入层所使用的技术方案而定。
+
+1.Nginx限流
+
+Nginx或其开源产品是最常用的Web服务器，我们使用的是TEngine。对于一个Web类应用，如Web页面或H5页面，我们通常会将限流策略增加到这一层，会设置QPS、并发数以及CPU的Idle作为限流指标。Nginx有对应的函数接口，可以获取到以上指标信息，然后通过Lua脚本实现限流的逻辑，并作为TEngine的插件安装即可。
+
+2.API路由网关模式
+
+对于客户端模式的接入，我们使用了API路由网关模式，一方面可以更方面地管理客户端与服务端的链接，另一方面也可以通过配置的方式管理服务接口，这里的服务管理会复用到微服务架构的配置中心，并实现相应的路由策略。对于QPS和并发限流，直接在配置中心中进行配置即可。
+
+第二类，应用限流。
+
+这一类的限流策略跟上面API路由网关模式的限流相似，同样是依赖配置中心管理，限流逻辑会配套服务化的框架完成。
+
+第三类，基础服务限流。
+
+主要针对数据库、缓存以及消息等基础服务组件的限流而设定。同样，限流逻辑会配套分布式数据库中间件，缓存或消息的框架来实现。
+
+讲到这里，我来解释几个关键的技术点。
+
+
+资源和策略。资源是我们要进行限流的对象，可能是一个应用，或者一个方法，也可能是一个接口或者URL，体现了不同的限流粒度和类型。策略就是限流的规则，比如下面我们要提到的QPS和并发数限流。
+时间精度。主要指对于QPS、并发数或CPU的阈值判断。比如对于QPS，我们就会设定一个QPS时间精度（假设3s），如果低于阈值则不启用策略，如果超过阈值就启动限流策略。
+指标计数。对于并发限制请求，会统计当前的并发数，1次请求进入到限流模块加1，等请求结束退出时减1，当前正在处理的请求数就是并发数。对于QPS限流，统计QPS不能按照秒统计，因为第1s，系统可能就被打挂了，所以QPS得按照毫秒级别去统计，统计的级别越小，性能损耗越大。所以定在10ms~100ms的级别去统计会更平滑一些，比如将1s切成10份，每一份100ms，一个请求进来肯定会落在某一份上，这一份的计数值加1。计算当前的QPS，只需要将当前时间所在份的计数和前面9份的计数相加，内存里面需要维护当前秒和前面2秒的数据。
+限流方式。对于Nginx就针对总的请求进行限流即可，但是粒度会比较粗。对于应用层，因为配置中心的灵活性，其限流就可以做得更细化。比如可以针对不同来源限流，也可以针对去向限流，粒度上可以针对类级别限流，也可以针对不同的方法限流，同时还可以针对总的请求情况限流，这些灵活策略都可以在微服务的配置中心实现。
+
+
+
+
+
+Spring AOP。对于Java应用，绝大多数公司都会用到Spring框架，包括我们上面讲到的分布式数据库等组件，也一样会依赖Spring框架，比如我们用到的MyBatis开源组件。而Spirng框架中的关键技术点，就是IoC和AOP，我们在限流方案的实现上，也会利用到相关技术。简单来说就是，我们通过配置需要限流的方法作为AOP的切入点，设定Advice拦截器，在请求调用某个方法，或请求结束退出某个方法时，进行上述的各种计数处理，同时决定是否要进行限流，如果限流就返回约定好的返回码，如果不限流就正常执行业务逻辑。基于AOP这样一个统一的技术原理，我们就可以开发出与业务逻辑无关的限流组件，通常会在对外的服务调用、数据库调用、缓存调用、消息调用这些接口方法上设置默认的切面，并在业务代码运行时注入，这样就可以做到对业务透明，无侵入性。
+Web类型的限流。对于Web类型URL接口限流，我们就利用Servlet的Filter机制进行控制即可。
+控制台。上面我们讲了各种配置和策略，如果都是通过人工来操作是不现实的，这时就需要开发对应的限流降级的控制台，将上述的各种配置和策略通过界面的方式进行管理，同时在配置完成之后，能够同步到对应的服务实例上。比如对于Nginx，当一个策略配置完成后，就要同步到指定的服务器上生成新的配置文件并Reload。对于配置中心模式的策略，也就是Spring AOP模式的限流，在控制台上配置完成后，就要将配置值同步更新到配置中心里，同时再通过运行时的依赖注入，在线上运行的业务代码中生效。
+
+
+整体简化的示意图如下：
+
+
+
+限流降级的难点
+
+上面整体介绍了限流降级的解决方案，我们可以看到涉及到很多新概念，各种不同的限流类型，同时还有比较复杂的技术细节，所以要清晰地理解这些概念。
+
+对于降级，主要是针对RT来进行判断，它的整个技术方案没有限流这么复杂，且思路上跟限流是相似的，所以我们就不再单独介绍降级的技术方案了。
+
+从整个建设过程来看，我的体会是，限流降级的难点和关键还是在于整体技术栈的统一，以及后期对每个应用限流降级资源策略的准确把握和配置。
+
+我们先来看整体技术栈的统一，这其实也就是我们在专栏最开始就讲到的标准化建设。这里我们会基于一个统一的技术栈进行限流降级方案的设计，要求有统一的Web服务器类型。对服务化框架、各类分布式框架以及代码开发框架（如Spring），这些都要有很明确的要求。如果这里面有某些应用使用的框架不同，那么这套统一的方案就无法推广落地。
+
+我们在实际推广过程中就遇到很多类似的问题，导致大量的时间耗费在技术栈统一上，甚至会要求业务代码做出改变和调整，代码上线运行后再进行统一，这个代价是非常大的。
+
+这也是为什么我们在一开始就非常强调标准化的重要性。这里我们再强调一下标准化，再来复习一下以应用为核心的运维体系的思维导图。
+
+
+
+再来看对应用的限流降级资源策略的把握，这个就需要对应用和业务有深入的了解。比如开发人员要非常清楚哪些接口是核心接口，它的来源和去向有哪些；哪些来源是核心的，哪些是非核心的；如果要限流，需要对哪些接口限流，同时要重点保障哪些接口等等。
+
+对于限流和降级的具体策略，就是QPS和并发数的配置，也要来源于线上实际运行维护的经验，才能知道配置多少是合适的，配置太大没有限流效果，太小又会频繁触发限流，影响正常业务运行。
+
+所以，限流和降级也是一个动态调测和完善的过程，对于有些动态变化的资源是做不到一劳永逸的。
+
+怎么办呢？一方面我们要依赖人的经验；另一方面，从最终的解决方案看，当调用次数和日志达到一定体量时，我们希望能够借助机器学习算法的手段，来帮助我们分析什么样的设置是最合理的。
+
+今天我们讨论了限流和降级的概念、解决方案以及难点，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/25稳定性实践：开关和预案.md

@@ -0,0 +1,78 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            25 稳定性实践：开关和预案
+                            在稳定性保障中，限流降级的技术方案，是针对服务接口层面的，也就是服务限流和服务降级。这里还有另外一个维度，就是业务维度，所以今天我们就从业务降级的维度来分享，也就是开关和预案。
+
+如何理解开关和预案
+
+开关，这个概念更多是业务和功能层面的，主要是针对单个功能的启用和停止进行控制，或者将功能状态在不同版本之间进行切换。
+
+在业务层面，就像我们前面经常提到的大促场景案例，我们会关闭掉很多非核心功能，只保留交易链路的核心功能。比如我们认为商品评论是非核心功能，这时就会通过开关推送这种方案将这个功能关闭。当用户访问商品详情页时，这个接口就不再被调用，从用户角度来说，就是在大促峰值时刻看不到所浏览商品的评论列表。
+
+在功能层面，我们技术架构中会使用缓存技术，但是要考虑到缓存有可能也会出现故障，比如不可访问，或者数据错乱异常等状况，这时我们就会考虑旁路掉缓存，直接将请求转到数据库这一层。
+
+这里有两种做法：一种做法是通过我们上一篇介绍到的降级手段，也就是我们常说的熔断，自动化地旁路；另一种做法，比如在数据异常情况下，请求是正常的，但是数据是有问题的，这时就无法做到自动化旁路，就要通过主动推送开关的方式来实现。
+
+预案，可以理解为让应用或业务进入到某种特定状态的复杂方案执行，这个方案最终会通过开关、限流和降级策略这些细粒度的技术来实现，是这些具体技术方案的场景化表现。
+
+我们还是接着上面的这个案例来讨论。因为每个业务或应用都会有自己的开关配置，而且数量会有很多，如果在大促前一个个推送，效率就会跟不上，所以我们就会针对某个应用的具体场景，提供批量操作的手段，通过预案场景将同一应用，甚至多个应用的开关串联起来。
+
+比如上面提到的商品详情页，我们不仅可以关闭商品评论，还可以关闭商品收藏提示、买家秀、店铺商品推荐、同类型商品推荐以及搭配推荐等等。有了场景化的预案，管理和维护起来就会更容易。
+
+除了业务层面的预案，我们还可以将预案应用到应急场景下，比如上面提到的缓存故障异常。在真实场景下，要考虑得更全面，比如缓存能够支撑的业务访问量是要远远大于数据库的，这时我们就要做功能降级，这就要考虑数据库是否能够支撑住这么大的请求量（通常情况下肯定是支撑不住的）。所以，遇到这种场景，我们首要考虑的是限流，先将业务流量限掉三分之一甚至是一半，然后再将功能降级到数据库上。
+
+这样就又涉及到多种策略的串行执行。如果没有预案都是单个执行的话，效率肯定会低，而且还可能涉及到多个应用都会执行相同的业务降级策略，这时就必须要有预案来统一管理，提前梳理好哪些应用需要在这种场景下执行对应的开关、限流和降级策略。
+
+技术解决方案
+
+技术方案上并不复杂，开关的字段主要以Key-Value方式管理，并从应用维度，通过应用名管理起来，这个对应关系就可以放到统一的控制台中管理。
+
+下图是整个开关和预案管理，以及推送的示意图，我们一起分步骤看一下。
+
+
+
+1.开关管理
+
+通过上述我们所说的Key-Value方式保存，与代码中的具体Field字段对应起来。这里就又会涉及到我们上篇内容中讲到的Spring的AOP和注解技术。
+
+如下面代码所示，我们通过注解方式定义了一个开关testKey，它与控制台中配置的Key相对应，并获取对应的Value取值，在业务运行阶段，我们就可以根据这个值，来决定业务执行逻辑，下面是简化的示例。
+
+@AppSwitcher(key="key1",valueDes = "Boolean类型")
+
+ private Boolean key1;
+
+代码中直接调用AppName对应的开关配置，进行不同业务逻辑的实现：
+
+Boolean key1 = MoguStableSwitch.isStableSwitchOn("key1");
+
+if (key1)
+{
+//开关打开时业务逻辑实现
+}else
+{
+//开关关闭时业务逻辑实现
+}
+
+
+2.开关推送
+
+当在控制台上修改开关值后，会推送到微服务的配置中心做持久化，这样当应用下次重启时依然可以获取到变更后的值。还有另外一种方式，就是通过HTTP的方式推送，这种情况的应用场景是，当第一种情况失败时，为了让开关快速生效预留的第二个接口。
+
+3.配置变更
+
+应用中引入的开关SDK客户端会监听对应配置的变更，如果发生变化，就会马上重新获取，并在业务运行时生效。
+
+4.预案执行
+
+就是多个开关策略的串行执行，会重复上面这几个关键步骤。
+
+关于开关和预案的内容，我们今天就介绍到这里。留一个问题，我们在上篇文章中介绍到限流降级方案的难点，请你思考一下，我们今天讲的开关预案这个内容，可能会遇到哪些难点呢？欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/26稳定性实践：全链路跟踪系统，技术运营能力的体现.md

@@ -0,0 +1,107 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            26 稳定性实践：全链路跟踪系统，技术运营能力的体现
+                            今天我们来分享全链路跟踪系统建设方面的内容。我们知道，随着微服务和分布式架构的引入，各类应用和基础组件形成了网状的分布式调用关系，这种复杂的调用关系就大大增加了问题定位、瓶颈分析、容量评估以及限流降级等稳定性保障工作的难度，如我们常见的调用网状关系。
+
+
+
+图片出自：https://www.linkedin.com/pulse/100-million-members-125-hours-watched-per-day-hundreds-probst/
+
+正是这样的背景，催生了分布式链路跟踪，也叫全链路跟踪的解决方案。
+
+关于这一块的技术解决方案，在Google的Dapper论文发表之后，近些年业界已经有非常多且非常成熟的实践经验和开源产品。
+
+比如阿里的鹰眼系统，就是全链路跟踪系统在国内的最佳实践；再比如美团点评的CAT分布式监控系统，也是从产品实践中逐步开源出来，在业界已经得到了非常广泛的应用；还有一些独立的开源产品，比如国内分布式监控技术专家吴晟创建的Skywalking项目，也是非常优秀的产品，而且也有比较广泛的应用。
+
+除此之外，还有大量优秀的商业产品，这类产品通常叫APM，应用性能管理系统，比如国内的听云、博瑞、OneAPM等等，他们在产品化方面做的会更完善，在很多场景下可以非常方便地落地应用。
+
+介绍上述这些产品，主要还是想说明，当前在分布式或全链路跟踪监控这个领域，无论是在技术还是产品层面都已经相对成熟，我们完全可以通过对这些产品的调研来选择适合自己的解决方案。
+
+蘑菇街在这块也是自研了一套体系，但是技术方案和思路上跟上述这些开源或商业产品都很相似，所以技术层面我就不再做详细赘述。
+
+如果想深入了解相关内容，一方面可以在网上找到非常多的资料，甚至是去阅读源码；另一方面还是推荐极客时间上陈皓老师的《左耳听风》专栏和杨波老师的《微服务架构核心20讲》，两位都是骨灰级的微服务和分布式架构专家，他们在技术层面的分享会更有深度和针对性。
+
+全链路跟踪系统在技术运营层面的应用
+
+接下来，主要分享我们利用全链路跟踪系统在技术运营层面做的一些事情，这里提到的运营，就是应用在线上运行时，我们根据应用运行数据所做的运行维护工作，这里我们会更加强调数据的作用。
+
+同时，这里的一个核心技术点就是 TraceID，当请求从接入层进来时，这个TraceID就要被创建出来；或者是通过Nginx插件方式创建放到http的header里面；或者是通过RPC服务化框架生成。然后在后续的请求中，这个字段会通过框架自动传递到下一个调用方，而不需要业务考虑如何处理这个核心字段。
+
+有了这个TraceID，我们就可以将一个完整的请求链路给串联起来了，这也是后面场景化应用的基础。下面我们就一起来看会有哪些具体的技术运营场景。
+
+第一个场景，问题定位和排查
+
+我们做全链路跟踪系统，要解决的首要问题就是在纷繁复杂的服务调用关系中快速准确地定位问题，所以这个场景是绕不开的。
+
+我们常见的问题场景，主要有两类：瓶颈分析和异常错误定位。
+
+首先看瓶颈分析。常见的问题就是某某页面变慢了，或者某个服务突然出现大量超时告警，因为无论是页面也好，还是服务也好，在分布式环境中都会依赖后端大量的其它服务或基础部件，所以定位类似的问题，我们期望能有一个详细的调用关系呈现出来，这样我们就可以非常方便快速地判断瓶颈出现在什么地方。
+
+比如下图的情况，就是某个页面变慢。我们根据URL查看某次调用的情况，就发现瓶颈是在RateReadService的query接口出现了严重阻塞。接下来，我们就可以根据详细的IP地址信息，到这台机器上或者监控系统上，进一步判断这个应用或者这台主机的异常状况是什么，可能是机器故障，也可能是应用运行故障等等。
+
+
+
+再来看一个案例。下图中我们可以看到，一次完整的请求耗时比较长，但是通过调用链分析会发现，其中任何一个单次请求的时延又非常低，并没有像上个案例那样有明显的请求瓶颈。我们再进一步分析，就会发现整个请求的列表非常长，且请求列表里面都是在访问缓存内容。很显然，这样的调用方式不合理，需要我们优化调用逻辑，要么通过批量接口方式，要么通过异步的方式，再或者要去分析业务场景是否合理。
+
+
+
+通过上面的案例，我们可以看到，在应用了全链路跟踪的解决方案后，复杂调用关系下的问题定位就相对简单多了。
+
+对于出现异常报错，也是一样的判断逻辑，限于篇幅我就不再赘述了。
+
+第二个场景，服务运行状态分析
+
+上面的问题定位，主要还是针对单次请求或相对独立的场景进行的。更进一步，我们在采集了海量请求和调用关系数据后，还可以分析出更有价值的服务运行信息。比如以下几类信息。
+
+1.服务运行质量
+
+一个应用对外可能提供HTTP服务，也可能提供RPC接口。针对这两类不同的接口，我们可以通过一段时间的数据收集形成服务接口运行状态的分析，也就是应用层的运行监控，常见的监控指标有QPS、RT和错误码，同时还可以跟之前的趋势进行对比。这样就可以对一个应用，以及对提供的服务运行情况有一个完整的视图。
+
+
+
+2.应用和服务依赖
+
+除了上述单个应用的运行状态，我们还可以根据调用链的分析，统计出应用与应用之间，服务与服务之间的依赖关系及依赖比例，如下图所示。
+
+
+
+这个依赖管理的作用，就是给我们前面介绍的容量压测和限流降级这两个工作做好准备。我们可以根据来源依赖和比例评估单链路的扩容准备；同时根据去向依赖进行流量拆分，为下游应用的扩容提供依据，因为这个依赖比例完全来源于线上真实调用，所以能够反映出真实的业务访问模型。
+
+同时，根据这个依赖关系，特别是服务依赖关系，我们还可以进一步分析依赖间的强弱关系，也就是强弱依赖。这一点又对我们做限流降级提供了对应的依据，也就是我们前面所说的，我们限流也好，降级也好，都是优先对非核心业务的限流和降级，这样的业务形成的依赖，我们就认为是弱依赖，是不关键的；但是对于核心业务我们就要优先保障，它们形成的依赖关系，是强依赖。无论是扩容也好，还是优化性能也罢，都要最大限度地确保强依赖关系的调用成功。
+
+所以，强弱依赖的分析，还是要从业务场景入手。比如对于电商来说，核心就是交易链路，我们就要判断如果一条链路上的某个应用或服务失败了，是不是会影响订购下单，或者影响支付收钱，如果影响，就要标注为强依赖，这个应用就要标注为核心应用；如果这个应用失败了，可以通过限流或降级的方式绕过，只是影响用户体验，但是不影响用户订购支付，那这个依赖关系就可以标注为弱依赖，该应用就可以标注为非核心应用。
+
+同时，因为我们的业务场景和需求在不断变化，应用和服务间的调用关系和依赖关系也是在不断变化中的，这就需要我们不断地分析和调整强弱依赖关系，同时也要关注各种调用间的合理性，这个过程中就会有大量的可优化的工作。
+
+通常情况下，这些事情对于业务架构师和运维人员来说，都会比较关注。因为业务架构师要对业务访问模型十分了解，他要经常关注这些信息；而运维会关注线上稳定性，需要在关键时刻执行限流降级或开关预案策略，所以也必须对这些信息非常熟悉。
+
+3.依赖关系的服务质量
+
+上面介绍了应用和服务间的依赖管理，同样的我们也会关注被依赖的应用或服务的实时运行状态和质量，这样就可以看到应用间实时的调用状态。是不是有的应用调用QPS突然增加了，或者RT突然暴涨，通过这个依赖关系就可以快速确认。
+
+
+
+第三类场景，业务全息
+
+顾名思义，业务全息就是全链路跟踪系统与业务信息的关联。从上述的介绍中，我们可以看到，全链路跟踪系统的应用更多的还是在技术层面，比如定位“应用或服务”的问题，应用或服务间的依赖关系等等。
+
+但是现实中，我们也会遇到大量的业务链路分析的场景，比如可能会有针对某个订单在不同阶段的状态等。假设一个情况是用户投诉，他的订单没有享受到满100元包邮的优惠，这时我们就要去查找用户从商品浏览、加购物车到下单整个环节的信息，来判断问题出在哪儿。其实，这个场景和一个请求的全链路跟踪非常相似。
+
+所以，为了能够在业务上也采用类似的思路，我们就将前面介绍到的请求链路上的唯一TraceID与业务上的订单ID、用户ID、商品ID等信息进行关联，当出现业务问题需要排查时，就会根据对应的ID将一串业务链整个提取出来，然后进行问题确认。这就会极大地提升解决业务问题的效率。
+
+总结
+
+今天我们从技术运营层面的应用这个角度重新认识了全链路跟踪系统。同时，从这个案例中，我们也应该看到，技术、产品和运营相辅相成，共同促进彼此的完善和成熟。
+
+全链路跟踪系统在技术方案的广泛应用，给我们提供了大量可分析处理的线上运行数据，从这些数据中，我们又能提炼出对线上稳定运行更有价值的信息。所以，技术之外，我们也应该更多地考虑技术在价值方面的呈现。
+
+今天的内容就介绍到这里，你在这方面遇到过哪些问题，有怎样的经验，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/27故障管理：谈谈我对故障的理解.md

@@ -0,0 +1,80 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            27 故障管理：谈谈我对故障的理解
+                            对于任何一个技术团队来说，最令人痛苦、最不愿面对的事情是什么？我想答案只有一个，那就是：故障。
+
+无论是故障发生时的极度焦虑无助，还是故障处理过程中的煎熬痛苦，以及故障复盘之后的失落消沉，都是我们不愿提及的痛苦感受。在海外，故障复盘的英文单词是Postmortem，它有另外一个意思就是验尸，想想就觉得痛苦不堪，同时还带有一丝恐怖的意味。
+
+写故障相关的文章，也着实比较痛苦。一方面回顾各种故障场景，确实不是一件令人愉悦的体验；另一方面，故障管理这个事情，跟技术、管理、团队、人员息息相关，也是一套复杂的体系。
+
+我们看Google SRE这本书（《SRE：Google运维解密》），绝大部分章节就是在介绍故障相关的内容。其实看看这本书就能明白稳定性和故障管理这项系统工程的复杂度了，而且从本质上讲，SRE的岗位职责在很大程度上就是应对故障。
+
+所以，接下来的几期文章，我会谈谈我对故障管理的理解，以及一些实际经历的感受，也希望我们每一个人和团队都能够在故障管理中得到涅槃重生。
+
+今天，先谈谈我们应该如何来看待故障这个事情。
+
+系统正常，只是该系统无数异常情况下的一种特例
+
+上面这句话，来自Google SRE这本书，我认为这是一个观点，但是更重要的，它更是一个事实。所以，正确理解故障，首先要接受这个现实。
+
+故障，是一种常态，任何一个软件系统都避免不了，国内最牛的BAT避免不了，国外最牛的Google、Amazon、Facebook、Twitter等也避免不了。业务体量越大，系统越复杂，问题和故障就越多，出现故障是必然的。
+
+可能你会有疑问，既然他们也存在各种故障，但是在我们的印象中，好像也没经常遇到这些大型网站整天出问题或不可访问的情况，这恰恰说明了这些公司的稳定性保障做得非常到位。
+
+这里有一个非常重要的体现，就是Design for Failure的理念。我们的目标和注意力不应该放在消除故障，或者不允许故障发生上，因为我们无法杜绝故障。所以，我们更应该考虑的是，怎么让系统更健壮，在一般的问题面前，仍然可以岿然不动，甚至是出现了故障，也能够让业务更快恢复起来。
+
+其实对这个理念的实践，我们在前面都已经介绍过了，比如限流降级、容量评估以及开关预案等技术方案的稳定性保障体系，这些技术方案本质上并不是为了杜绝故障发生，而是为了能够更好地应对故障。
+
+同样的，我们刚提到的那些国内外超大型网站，之所以能够保持很高的稳定性和业务连续性，恰恰是说明他们在故障隔离、快速恢复、容灾切换这些方面做得非常优秀，一般的问题或故障，根本不会影响到业务访问。
+
+所以，转变一下思路，重新理解系统运行的这种特点，会给我们后续在如何面对故障、管理故障的工作中带来不一样的思考方式。
+
+故障永远只是表面现象，其背后技术和管理上的问题才是根因
+
+简单表述一下，就是永远不要将注意力放在故障本身上，一定要将注意力放到故障背后的技术和管理问题上去。
+
+这里的逻辑是这样的，技术和管理上的问题，积累到一定量通过故障的形式爆发出来，所以故障是现象，是在给我们严重提醒。
+
+有时我们过分关注故障本身，就容易揪着跟故障相关的责任人不放，这样会给责任人造成很大的负面压力，进而导致一些负面效应的产生，这一块在后面我还会专门分享。
+
+与之对应的改进措施，往往就容易变成如何杜绝故障。前面我们讲到，从现实情况看这是完全不可能的，所以就容易输出一些无法落地、无法量化的改进措施。
+
+你可以思考一下，面对故障的时候，是不是经常出现上述这两种情况。
+
+所以，想要更好地应对和管理故障，当故障发生后，我们需要考虑的问题应该是其背后存在的技术和管理问题。这里和你分享我自己在故障后的复盘中，经常会反思和提出的几个问题。
+
+
+为什么会频繁出故障？是不是人员技术不过硬？人为操作太多，自动化平台不完善，操作没有闭环？代码发布后的快速回滚措施不到位？
+为什么一个小问题或者某个部件失效，会导致全站宕机？进一步考虑，是不是业务高速发展，技术架构上耦合太紧，任何一个小动作都可能是最后一根稻草？是不是容量评估靠拍脑袋，系统扛不住才知道容量出问题了？是不是限流降级等保障手段缺失，或者有技术方案，但是落地效果不好？
+为什么发生了故障没法快速知道并且快速恢复？进一步考虑，是不是监控不完善？告警太多人员麻木？定位问题效率低，迟迟找不到原因？故障隔离还不够完善？故障预案纸上谈兵？
+管理上，团队成员线上敬畏意识不够？还是我们宣传强调不到位？Oncall机制是否还需要完善？故障应对时的组织协作是不是还有待提升？
+
+
+总结下来，任何一个故障的原因都可以归结到具体的技术和管理问题上，在故障复盘过程中，通常会聚焦在某个故障个例上，归纳出来的是一个个非常具体的改进措施。
+
+用一句话总结：“理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。”（From SRE ，by Brian Redman）
+
+最后，作为管理者，我会问自己一个终极问题：下次出现类似问题，怎么才能更快地发现问题，更快地恢复业务？即使这一次的故障应对已经做得非常好了，下次是否可以有更进一步的改进？
+
+这个问题，会促使我个人更加全面地思考，且能够关注到更全局的关键点上。比如，是不是应该考虑有更加完善的发布系统，减少人为操作；是不是应该有整体的稳定性平台建设，包括限流降级、开关预案、强弱依赖、容量评估、全链路跟踪等子系统，以及建设完成后，应该如何一步步的落地；还有，故障预案和演练应该如何有效的组织起来，毕竟这些是从全局考虑，自上而下的一个过程。
+
+最后
+
+再表达两个观点。
+
+第一，出问题，管理者要先自我反省。不能一味地揪着员工的错误不放，员工更多的是整个体系中的执行者，做得不到位，一定是体系上还存在不完善的地方或漏洞。在这一点上，管理者应该重点反思才对。
+
+第二，强调技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题，技术手段暂时无法满足的，可以靠管理手段来辅助。比如我上面提到的就基本都是技术手段，但是要建设一个完善的体系肯定要有一个过程，特别是对于创业公司。这时可以辅以一些管理措施，比如靠宣传学习，提升人员的线上安全稳定意识，必要的Double Check，复杂操作的Checklist等，但是这些只能作为辅助手段，一定不能是常态，必须尽快将这些人为动作转化到技术平台中去。
+
+这样做的原因也很明显，单纯的管理手段还是靠人，跟之前没有本质区别，只不过是更加谨小慎微了一些而已。同时，随着系统复杂度越来越高，迟早有一天会超出单纯人力的认知范围和掌控能力，各种人力的管理成本也会随之上升。
+
+今天和你分享了我对故障这件事情的理解，期望这样一个不同角度的理解能够带给你一些启发，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/28故障管理：故障定级和定责.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            28 故障管理：故障定级和定责
+                            故障管理的第一步是对故障的理解，只有正确地面对故障，我们才能够找到更合理的处理方式。今天就来和你分享关于故障定级和定责方面的经验。
+
+故障的定级标准
+
+上期文章中介绍到，如果我们的注意力仅仅盯着故障本身，就非常容易揪着责任人不放，进而形成一些负面效应，所以我们要将更多的注意力放到故障背后的技术和管理问题上。
+
+但是，这并不是说对故障本身就可以不重视，相反，故障发生后，一定要严肃对待。这里就需要制定相应的标准和规范来指导我们的处理过程。这个过程并不是一定找出谁来承担责任，或者一定要进行处罚，而是期望通过这样的过程，让我们能够从故障中深刻地认识到我们存在的不足，并制定出后续的改进措施。
+
+这里有一个关键角色，我们称之为技术支持，也有的团队叫 NOC（Network Operation Center）。这个角色主要有两个职责：一是跟踪线上故障处理和组织故障复盘，二是制定故障定级定责标准，同时有权对故障做出定级和定责，有点像法院法官的角色，而上面的两个标准就像是法律条款，法官依法办事，做到公平公正。
+
+所以，这里的一个关键就是我们要有明确的故障定级标准。这个标准主要为了判定故障影响程度，且各相关利益方能够基于统一的标准判断和评估。
+
+现实情况中，因为各方受到故障的影响不同，对故障影响的理解也不同，所以复盘过程中，经常会出现下面这两种争执场景。
+
+
+技术支持判定故障很严重，但是责任方认为没什么大不了的，不应该把故障等级判定到如此之高；
+技术支持认为故障影响较小，但是受影响方却认为十分严重，不应该将故障等级判定得这么低。
+
+
+遇到这种情况，技术支持作为故障判定的法官，就必须拿出严格的判定标准，并说明为什么这么判定。
+
+我们将故障等级设置为P0~P4这么5个级别，P0为最高，P4为最低。对于电商，主要以交易下跌、支付下跌、广告收入资损这些跟钱相关的指标为衡量标准。对于其他业务如用户IM等，主要区分业务类型，制定符合业务特点的定级标准。两个示例如下。
+
+交易链路故障定级标准示例：
+
+
+
+用户IM故障定级标准示例：
+
+
+
+故障定级的标准，会由技术支持与各个业务研发团队进行点对点的细节沟通讨论，从业务影响角度把影响面、影响时长这些因素串联起来。这样即使在后续出现争执，也会有对应的标准参考。这个标准可能覆盖不到有些故障影响或特例，但是技术支持可以根据自己的经验进行“自由裁量”。同时，每个季度或半年对标准进行一次修订和完善。这样，我们前面提到的争执就会越来越少，再加上我们内部树立了“技术支持角色拥有绝对话语权和决策权”的制度，执行过程中就会顺畅很多。
+
+对于P0故障，通常是由两个级以上的P1故障叠加造成的，这说明已经发生了非常严重的全站故障。
+
+不同的故障定级，在故障应对时采取的策略也就不同。一般来说，P2及以上故障就需要所有相关责任人马上上线处理，并及时恢复业务。对于P3或P4的问题，要求会适当放宽。整个过程，技术支持会给出一个基本判断，然后会组织召集临时故障应急小组处理。
+
+关于全年全站，或者分业务的可用性和可靠性，这个可以借鉴业界通用的MTBF（Mean Time Between Failures，平均故障间隔时间）、MTTR（Mean Time To Recovery，平均修复时间）、MTTF（Mean Time To Failure，平均失效前时间）这几个指标来衡量，这里我们就不详细介绍了。
+
+故障的定责标准
+
+上述的故障定级标准，主要是用来判定故障等级，使得故障相关方不至于过分纠结在等级标准上。而故障定责的主要目的是判定责任方。这就需要有明确的故障定责标准，我认为有两个主要目的。
+
+
+避免扯皮推诿。比如我认为是你的责任，你认为是我的责任，大家争执不清，甚至出现诋毁攻击的情况。
+正视问题，严肃对待。不是为了处罚，但是作为责任方或责任团队一定要正视问题，找出自身不足，作为改进的主要责任者，来落地或推进改进措施。
+
+
+关于第一点，避免扯皮推诿，大概是很多团队都会遇到的非常头疼的问题，也是最令人生厌的问题，所以避免这样的问题，就必须得有相对清晰的定责标准。
+
+比如我们经常会提到的运维背锅的说法，这种情况出现的场景经常是，某个核心功能出现了故障，有大量超时或失败，对应的开发定位一下，说我的代码没有问题，场景也没复现，这个应该是运维负责的主机、网络或者其他基础服务有问题吧，这个责任很轻易地就甩给了运维。类似的上游把责任推脱到下游的情况是经常出现的。
+
+我们自己的实践，是严禁这种情况出现的。也就是作为受影响方，开发负责人有责任端到端地把问题定位清楚，只有当定位出来的问题确实是发生在运维的某个部件时，才允许将责任传递 ，否则不允许出现将自己的问题简单排除，就推断或者感觉应该是其他责任方的问题，然后终止后续排查或者指定下游责任方的情况出现。
+
+当然，在这个过程中，如果需要配合，是可以要求各方投入支持的，因为共同的目标还是要清晰定位问题，找到解决方案。
+
+这时候，就更加需要开放和宽松的氛围，如果大家始终朝着如何摆脱责任或甩锅的目标行事，就会出现非常负面的效应，这一点后面我们会详细分享。
+
+关于定责，我们划分了几个维度，我简单示例如下。
+
+1.变更执行
+
+比如变更方没有及时通知到受影响方，或者事先没有进行充分的评估，出现问题，责任在变更方；如果通知到位，受影响方没有做好准备措施导致出现问题，责任在受影响方；变更操作的实际影响程度大大超出预期，导致受影响方准备不足出现故障，责任在变更方。
+
+2.服务依赖
+
+比如私自调用接口，或者调用方式不符合约定规则，责任在调用方；如果是服务方没有明确示例或说明，导致调用方出现问题，责任在服务方等等。
+
+3.第三方责任
+
+比如机房IDC电力故障、服务器故障、运营商网络故障等等，如果确实是不可抗力导致，责任在第三方；但是因自身的冗余或故障预案问题导致故障，责任在应用Owner。
+
+有了这样的原则，在故障复盘时，就可以有效减少不和谐氛围的出现。因为每个公司的业务形态和特点不一样，里面的具体内容可能也不一样，上述的定责标准可能不完全适用，所以仅供示例参考。如果你在日常深受故障定责的困扰，建议尽快把规则明确起来，并能够与各方达成一致，这样就会最大程度地减少扯皮推诿的情况出现。
+
+总结
+
+今天我们讨论了故障管理中的定级和定责标准。蘑菇街在这方面的具体管理执行中，还是取得了不错的效果，所以分享出来，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/29故障管理：鼓励做事，而不是处罚错误.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            29 故障管理：鼓励做事，而不是处罚错误
+                            故障发生后，我们一定要严肃对待，要对关键责任人或责任方定责，但是定责的目的不是处罚，因为故障复盘一旦以处罚为导向，就会导致非常严重的负面效应。
+
+我们应该如何对待定责和处罚呢？今天就来分享一下我的理解，以及我个人的一些处理方式。
+
+关于定责和处罚
+
+定责的过程，是找出根因，针对不足找出改进措施，落实责任人。定责的目的，是责任到人，并且责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。同时，也让整个团队认识到，我们对于故障的态度一定是严肃严格的。
+
+但是，在具体的执行过程中，我们一定要区分定责和处罚。定责是对事不对人的，但是处罚就变成对人不对事了，因为处罚一定会跟薪资、奖金、绩效、晋升等这些跟个人利益相关的事情直接挂钩。
+
+我的观点是，处罚不能一刀切，更不能上纲上线，一定要慎重。
+
+关于是否处罚，我个人认为可以遵循这样的原则：对于有明确底线，坚决不允许触碰的规则，如果因不遵守规则，故意触犯，导致了严重故障的出现，这种情况是要处罚的。
+
+这样的规则建议通过设定高压线的方式让团队成员牢记心中，就像“酒后不开车”一样，简单明确。我大致列举几条我们的“高压线规则”。
+
+
+未经发布系统，私自变更线上代码和配置；
+未经授权，私自在业务高峰期进行硬件和网络设备变更；
+未经严格的方案准备和评审，直接进行线上高危设备操作，如交换机、路由器防火墙等；
+未经授权，私自在生产环境进行调测性质的操作；
+未经授权，私自变更生产环境数据信息。
+
+
+通过高压线去加强安全稳定意识，目的是要让每一个人对线上都心存敬畏。从我们的经验来看，绝大多数的严重故障都是因为无意识或意识薄弱导致的，并不是因为单纯的技术能力不足等技术因素。特别是那种自我感觉没问题，就把命令噼里啪啦敲到线上的操作，是最致命的。
+
+2016年是公司业务高速发展的阶段，设备扩容比较频繁，网络割接操作也很多。因为没有明确严格的规则，导致团队成员为了赶工期，在白天进行网络设备变更，结果就是严重的P0和P1故障频发。复盘过程中，很多人的反馈就是：我以为是没问题的，我以为是没影响的。其实恰恰就是因为这种“想当然”，导致了严重故障。
+
+后来我们总结，在这些关键的操作上，如果大家意识到位，能够谨小慎微，绝大多数低级失误都是可以避免的，所以针对这些场景，我们就专门制定了高压线。
+
+制定高压线的效果也是很明显的。在近两年的时间里，我们没有出现过任何一例因为意识缺失或低级失误导致的P0和P1故障。反倒是跟我们有产品技术合作的第三方厂商，有时会出问题，我们了解下来，基本都是白天变更导致的，要么是没有放到凌晨实施，要么就是白天临时变更，没有准备充分。
+
+所以，制定明确的高压线规则，提升意识，碰一次就要疼一次。这个时候的惩罚是为了提升责任人的敬畏意识和主观意识，人为失误才会减少，处罚也才会有效。
+
+当然，更好的结果是，类似的故障越来少，处罚的执行也基本没有了。
+
+鼓励做事，而不是处罚错误
+
+前面我们分享过这句话：
+
+
+理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。（From SRE ，by Brian Redman）
+
+
+我想很多朋友跟我一样，都会产生共鸣。仔细考虑一下，我们每个人的技术能力提升，甚至是质的提升，基本都是伴随着大大小小故障的发生、处理、复盘和改进，这样一个过程提升起来的。
+
+虽然我们不希望有故障发生，但是真的没有了故障，我们也就没有了真刀真枪实战成长的机会。我们对待故障一定要客观和辩证地理解，特别是对于管理者来说，对于故障，一定要有容忍度，一定要有耐心。
+
+发生故障一方面暴露出我们整体技术架构的不足之处，另一方面，也给我们提供了未来改进的方向。同时，也是最重要的，我们的团队和人员，在这样一次次痛苦的经历后，各方面的能力都得到了锻炼，团队和个人素养也一定会有大幅度提升。所以，对故障有容忍度，有耐心，我们的团队就会变得越来越强，对于故障的应对也会变得更加游刃有余。
+
+反观另一种管理方式，一出故障就劈头盖脸地把团队和责任人骂一通，并且还要严厉处罚的方式，最后的效果就是严重打击士气，适得其反。
+
+所以，作为管理者，当一个故障发生之后，除故障本身外，还要关注更全面的内容，比如关注人、事情背景和前因后果。
+
+列举一下我之前经常遇到的两种情况。
+
+1.员工积极主动地承担了一些极具挑战性的工作，需要尝试某个新技术或解决方案，而团队、业界和社区可能都没有可供直接借鉴的经验，结果在落地的过程中踩到了一些坑，导致出现了问题。
+
+这种情况在成熟的技术和产品中也极容易出现，比如开源产品，有时候不翻源码都不知道某个地方埋着深坑。即使是商业产品，像Oracle在他的官方bug库里列着一堆已知bug，就是明确告知用户使用时要非常小心，真的碰到bug了，官方一般也是建议升级版本。根据我的经验，对于这样一个庞大的bug库，不出问题一般没人会去把整个bug list都看一遍的。
+
+2.业务高速发展时期，业务量成指数级增长时，团队人员技能和经验水平整体上还没法很好地应对，这个时候可能任何一个小变动都是最后一根稻草。这种时候就需要群策群力，而不是简单处罚了事。
+
+这两种情况都需要全面了解信息之后，再做判断。甚至要优先传递信任，而不是不管三七二十一就直接批评和处罚。何况，如果不出问题，可能很多主管压根都没有关注过员工在做的事情，过程中是否有困难，是否需要支持等等，这本身就是管理者的失责。
+
+在当前这种新业务和新形态不断涌现，又要求快速迭代的背景下，软件开发这种技术工作很大程度上还是要依赖员工的创新和创造。所以在很多情况下，管理者一定要对故障有一定的容忍度，因为员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，而且想要再恢复起来也会非常困难，最终很大概率上会导致优秀人才流失，为别人做了嫁衣。
+
+所以，团队内部一定要营造出鼓励做事向前冲的氛围，而不是制造担心犯错误被处罚的恐慌氛围。
+
+处罚的“负”作用远超我们的想象
+
+前面讲到，定责不是处罚，是就事论事。员工哪些地方做得不到位，是能力不足还是经验欠缺，这些东西主管可以基于事实，很正式、严肃地表达出来。通常情况下，员工也大多是可以接受的。同时帮助员工进一步分析应该怎么提升，或者聆听员工有什么求助或困难。这种情况下，员工的感受是，主管尊重我，在帮助我。
+
+但是，话题和目的一旦转到处罚相关的事情，员工一般会有两种类型的反应：一种是消沉低落（反正都是我的错，你说咋样就咋样）；另外一种是极力地反抗和质疑（凭什么罚我不罚别人，又不是我一个人的问题等等）。
+
+这时，员工的注意力也会从怎么改进，转变到为什么要处罚我的角度上来。在这种消极和抵抗情绪中再去沟通什么改进措施，就没有任何效果了。作为管理者，也就非常容易陷入到与被沟通者的反复解释中，他质疑一句，你就解释一句，但是他压根就没听进去。
+
+从我们的经验来看，如果定责跟绩效强挂钩，团队就陷入这种恐慌、质疑、挑战以致最终相互不信任的局面。员工害怕、甚至拒绝承担责任，宁可少做不做，也不愿多做多错，团队沟通成本上升，运作效率自然下降。特别是一个故障如果是涉及多方的，扯皮推诿就开始了，都想着把责任撇干净，甚至当众相互指责，这个负面效应杀伤力极大。
+
+后来我们就取消挂钩，对于出现的故障有专门的系统记录，然后把这件事情放到员工一个季度，半年，甚至一年表现中进行整体判断。如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但如果是频繁出问题，这种情况就基于事实反馈，也会更加容易沟通。
+
+我的团队中，就出现过类似的情况。有员工导致了线上严重故障，当个季度绩效较差，但是因为全年表现突出，年终仍然是优秀；也有员工，因为连着两个季度触碰高压线，全年又无明显突出的表现，年终绩效也就不理想。
+
+总结
+
+我们做个小总结，对于故障的态度，我们还是得要辩证地看。对于是否处罚，也要具体问题具体分析。完全不处罚，或者一刀切，一律处罚都是不可取的。作为管理者，还是要将规则和标准定义清楚，在执行时才能够做到公平公正。
+
+另外，管理者除了关注故障本身之外，还要考虑得更加全面一些，要关注到人的感受，关注事情的前因后果，只有这样，在管理执行过程中才会让员工感受到尊重和信任。
+
+最后，你在故障定责和处罚方面有什么经历和想法，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/30故障管理：故障应急和故障复盘.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            30 故障管理：故障应急和故障复盘
+                            故障发生后，我们一定要严肃对待，要对关键责任人或责任方定责，但是定责的目的不是处罚，因为故障复盘一旦以处罚为导向，就会导致非常严重的负面效应。
+
+我们应该如何对待定责和处罚呢？今天就来分享一下我的理解，以及我个人的一些处理方式。
+
+关于定责和处罚
+
+定责的过程，是找出根因，针对不足找出改进措施，落实责任人。定责的目的，是责任到人，并且责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。同时，也让整个团队认识到，我们对于故障的态度一定是严肃严格的。
+
+但是，在具体的执行过程中，我们一定要区分定责和处罚。定责是对事不对人的，但是处罚就变成对人不对事了，因为处罚一定会跟薪资、奖金、绩效、晋升等这些跟个人利益相关的事情直接挂钩。
+
+我的观点是，处罚不能一刀切，更不能上纲上线，一定要慎重。
+
+关于是否处罚，我个人认为可以遵循这样的原则：对于有明确底线，坚决不允许触碰的规则，如果因不遵守规则，故意触犯，导致了严重故障的出现，这种情况是要处罚的。
+
+这样的规则建议通过设定高压线的方式让团队成员牢记心中，就像“酒后不开车”一样，简单明确。我大致列举几条我们的“高压线规则”。
+
+
+未经发布系统，私自变更线上代码和配置；
+未经授权，私自在业务高峰期进行硬件和网络设备变更；
+未经严格的方案准备和评审，直接进行线上高危设备操作，如交换机、路由器防火墙等；
+未经授权，私自在生产环境进行调测性质的操作；
+未经授权，私自变更生产环境数据信息。
+
+
+通过高压线去加强安全稳定意识，目的是要让每一个人对线上都心存敬畏。从我们的经验来看，绝大多数的严重故障都是因为无意识或意识薄弱导致的，并不是因为单纯的技术能力不足等技术因素。特别是那种自我感觉没问题，就把命令噼里啪啦敲到线上的操作，是最致命的。
+
+2016年是公司业务高速发展的阶段，设备扩容比较频繁，网络割接操作也很多。因为没有明确严格的规则，导致团队成员为了赶工期，在白天进行网络设备变更，结果就是严重的P0和P1故障频发。复盘过程中，很多人的反馈就是：我以为是没问题的，我以为是没影响的。其实恰恰就是因为这种“想当然”，导致了严重故障。
+
+后来我们总结，在这些关键的操作上，如果大家意识到位，能够谨小慎微，绝大多数低级失误都是可以避免的，所以针对这些场景，我们就专门制定了高压线。
+
+制定高压线的效果也是很明显的。在近两年的时间里，我们没有出现过任何一例因为意识缺失或低级失误导致的P0和P1故障。反倒是跟我们有产品技术合作的第三方厂商，有时会出问题，我们了解下来，基本都是白天变更导致的，要么是没有放到凌晨实施，要么就是白天临时变更，没有准备充分。
+
+所以，制定明确的高压线规则，提升意识，碰一次就要疼一次。这个时候的惩罚是为了提升责任人的敬畏意识和主观意识，人为失误才会减少，处罚也才会有效。
+
+当然，更好的结果是，类似的故障越来少，处罚的执行也基本没有了。
+
+鼓励做事，而不是处罚错误
+
+前面我们分享过这句话：
+
+
+理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。（From SRE ，by Brian Redman）
+
+
+我想很多朋友跟我一样，都会产生共鸣。仔细考虑一下，我们每个人的技术能力提升，甚至是质的提升，基本都是伴随着大大小小故障的发生、处理、复盘和改进，这样一个过程提升起来的。
+
+虽然我们不希望有故障发生，但是真的没有了故障，我们也就没有了真刀真枪实战成长的机会。我们对待故障一定要客观和辩证地理解，特别是对于管理者来说，对于故障，一定要有容忍度，一定要有耐心。
+
+发生故障一方面暴露出我们整体技术架构的不足之处，另一方面，也给我们提供了未来改进的方向。同时，也是最重要的，我们的团队和人员，在这样一次次痛苦的经历后，各方面的能力都得到了锻炼，团队和个人素养也一定会有大幅度提升。所以，对故障有容忍度，有耐心，我们的团队就会变得越来越强，对于故障的应对也会变得更加游刃有余。
+
+反观另一种管理方式，一出故障就劈头盖脸地把团队和责任人骂一通，并且还要严厉处罚的方式，最后的效果就是严重打击士气，适得其反。
+
+所以，作为管理者，当一个故障发生之后，除故障本身外，还要关注更全面的内容，比如关注人、事情背景和前因后果。
+
+列举一下我之前经常遇到的两种情况。
+
+1.员工积极主动地承担了一些极具挑战性的工作，需要尝试某个新技术或解决方案，而团队、业界和社区可能都没有可供直接借鉴的经验，结果在落地的过程中踩到了一些坑，导致出现了问题。
+
+这种情况在成熟的技术和产品中也极容易出现，比如开源产品，有时候不翻源码都不知道某个地方埋着深坑。即使是商业产品，像Oracle在他的官方bug库里列着一堆已知bug，就是明确告知用户使用时要非常小心，真的碰到bug了，官方一般也是建议升级版本。根据我的经验，对于这样一个庞大的bug库，不出问题一般没人会去把整个bug list都看一遍的。
+
+2.业务高速发展时期，业务量成指数级增长时，团队人员技能和经验水平整体上还没法很好地应对，这个时候可能任何一个小变动都是最后一根稻草。这种时候就需要群策群力，而不是简单处罚了事。
+
+这两种情况都需要全面了解信息之后，再做判断。甚至要优先传递信任，而不是不管三七二十一就直接批评和处罚。何况，如果不出问题，可能很多主管压根都没有关注过员工在做的事情，过程中是否有困难，是否需要支持等等，这本身就是管理者的失责。
+
+在当前这种新业务和新形态不断涌现，又要求快速迭代的背景下，软件开发这种技术工作很大程度上还是要依赖员工的创新和创造。所以在很多情况下，管理者一定要对故障有一定的容忍度，因为员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，而且想要再恢复起来也会非常困难，最终很大概率上会导致优秀人才流失，为别人做了嫁衣。
+
+所以，团队内部一定要营造出鼓励做事向前冲的氛围，而不是制造担心犯错误被处罚的恐慌氛围。
+
+处罚的“负”作用远超我们的想象
+
+前面讲到，定责不是处罚，是就事论事。员工哪些地方做得不到位，是能力不足还是经验欠缺，这些东西主管可以基于事实，很正式、严肃地表达出来。通常情况下，员工也大多是可以接受的。同时帮助员工进一步分析应该怎么提升，或者聆听员工有什么求助或困难。这种情况下，员工的感受是，主管尊重我，在帮助我。
+
+但是，话题和目的一旦转到处罚相关的事情，员工一般会有两种类型的反应：一种是消沉低落（反正都是我的错，你说咋样就咋样）；另外一种是极力地反抗和质疑（凭什么罚我不罚别人，又不是我一个人的问题等等）。
+
+这时，员工的注意力也会从怎么改进，转变到为什么要处罚我的角度上来。在这种消极和抵抗情绪中再去沟通什么改进措施，就没有任何效果了。作为管理者，也就非常容易陷入到与被沟通者的反复解释中，他质疑一句，你就解释一句，但是他压根就没听进去。
+
+从我们的经验来看，如果定责跟绩效强挂钩，团队就陷入这种恐慌、质疑、挑战以致最终相互不信任的局面。员工害怕、甚至拒绝承担责任，宁可少做不做，也不愿多做多错，团队沟通成本上升，运作效率自然下降。特别是一个故障如果是涉及多方的，扯皮推诿就开始了，都想着把责任撇干净，甚至当众相互指责，这个负面效应杀伤力极大。
+
+后来我们就取消挂钩，对于出现的故障有专门的系统记录，然后把这件事情放到员工一个季度，半年，甚至一年表现中进行整体判断。如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但如果是频繁出问题，这种情况就基于事实反馈，也会更加容易沟通。
+
+我的团队中，就出现过类似的情况。有员工导致了线上严重故障，当个季度绩效较差，但是因为全年表现突出，年终仍然是优秀；也有员工，因为连着两个季度触碰高压线，全年又无明显突出的表现，年终绩效也就不理想。
+
+总结
+
+我们做个小总结，对于故障的态度，我们还是得要辩证地看。对于是否处罚，也要具体问题具体分析。完全不处罚，或者一刀切，一律处罚都是不可取的。作为管理者，还是要将规则和标准定义清楚，在执行时才能够做到公平公正。
+
+另外，管理者除了关注故障本身之外，还要考虑得更加全面一些，要关注到人的感受，关注事情的前因后果，只有这样，在管理执行过程中才会让员工感受到尊重和信任。
+
+最后，你在故障定责和处罚方面有什么经历和想法，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/31唇亡齿寒，运维与安全.md

@@ -0,0 +1,73 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            31 唇亡齿寒，运维与安全
+                            故障管理模块告一段落了，今天我们来分享运维安全的内容。在日常工作中，我们运维团队和安全团队的配合确实是非常紧密的，有非常多的交集，我觉得可以做个整体的分享，算是抛砖引玉，以激发更多的讨论和思考。
+
+运维和安全的关系
+
+运维和安全，双方有一个共同的特点，就是时常要面对非常棘手，甚至是影响公司口碑声誉的问题。对于安全来说，这一点尤甚，想一想用户信息泄露会造成什么样的后果就不难理解了。
+
+所以，运维和安全的合作，最初都是在这种场景下触发的，也就让两个团队显得更像是难兄难弟。
+
+另外一层关系，就像我们今天分享的题目，运维和安全的关系，就是唇亡齿寒的关系。因为安全是整个业务和技术体系的一道防线，当这道防线被突破，最直接的影响和损失就体现在主机、系统和数据上，而这些又正好是运维的范畴。说得直白一点，就是一旦发生了安全事故，造成的影响，以及后续的修复，这些工作都将由运维来承担。
+
+所以，在双方工作的协作上，我一直认为运维不能只是被动响应，而应该主动与安全合作，共建安全体系，与运维体系融合，把防线建设好，从源头控制。
+
+同时，安全问题和需求一般都会放置在较高优先级上来响应，并通过固定的问题响应机制实行联动，从而实现最高效的配合响应。
+
+蘑菇街安全体系简介
+
+这里首先介绍一下我们的安全体系，限于篇幅，我只对部分关键系统和平台做一个简要概述，同时会介绍一下每个系统与运维系统之间的关系。
+
+1.入网管控
+
+这是VPN接入的管控，并与员工的统一登录鉴权结合，做到一键登录。因为VPN接入后，就等于进入了线上的网络环境中，可以访问到很多敏感系统和数据，这里的入网管控就相当于整个环境的第一道防线。
+
+2.堡垒机
+
+当接入VPN之后，对于技术同学就会有进一步的需求，比如访问线下和线上环境，登录主机和网络设备做维护工作，这时我们就需要有另外一道关卡，就是硬件或虚拟设备的登录管控，这个就由堡垒机来实现。这里堡垒机维护的主机列表、主机用户名、权限配置等信息，就需要与运维系统中的CMDB以及运维标准化的内容保持统一。
+
+因为堡垒机基本属于每个公司安全建设的第一个产品，所以属于强需求，业界也随之出现了很多优秀的开源及商业产品，你可以自行了解一下。同时，关于这块内容，我们的安全工程师齐剑涛在2017年CUNTCon全球运维技术大会上做过分享，如果有兴趣可以进一步了解。
+
+固守服务器的第一道防线——美联集团堡垒机的前世今生
+
+3.主机安全管控
+
+在每台主机上运行一个安全Agent，实时地对可疑进程、可疑端口、可疑账号、可疑日志以及各类操作进行监控，一旦发现异常就会及时告警，确保能够第一时间发现异常，这种就可以一定程度上对黑客入侵导致的破坏进行控制。
+
+4.黑盒扫描
+
+这个系统主要针对主机上对外开放的端口和使用的服务进行扫描。比如我们之前遇到的Redis高危端口漏洞，OpenSSL心脏滴血漏洞等，同时从接入层会过滤出高频的url，通过注入或修改消息来模拟恶意攻击，量虽不会大，但是如果存在异常或高危漏洞就可以及时发现，同时这个扫描是不间断的。
+
+5.白盒扫描（代码审计）
+
+这个系统我们在前面的持续交付流水线中介绍过，会针对代码中明显的漏洞进行审计，比如XSS漏洞，SQL注入等问题，如果在代码中存在类似问题是不允许发布上线的。
+
+这个项目已经开源，地址：https://github.com/WhaleShark-Team/cobra
+
+这样，黑盒和白盒扫描搭配起来，就可以对内外部的服务和系统进程进行全方位的保障了。
+
+6.WAF，Web Application Firewall
+
+WAF用来对外部的Web服务进行保护。我们知道，对于业务系统来说，通常会有很多不正规的渠道来网站爬取各种信息，更有甚者会通过模拟用户行为来注册大量虚假账号，以此来领取各种优惠，或者提交大量虚假订单、评论等等，同时还会对服务器负载造成很大压力。对于这种恶意行为，就需要由WAF来保护，通过一定的业务规则配置和识别来阻止恶意访问。
+
+7.应急响应中心SRC
+
+在安全界，有这样一个不成文的说法，叫作三分靠技术，七分靠人脉，也就是安全的信息情报有时比单纯的技术攻防要重要得多。对于企业来说，除了要能够招聘到一些安全圈内的专业人士，另一方面，也要有对外公开的应急响应中心SRC，以此来聚集一些比较友好和善意的白帽子，通过他们主动发现一些网站和系统的漏洞，并能够通过SRC提交给公司安全部门。同时，作为企业也会有一些不同形式的奖励，比如奖金和纪念品这样的物质奖励，或者漏洞提交排名这样名誉上的认可，以此来形成更长久和深入的合作。
+
+同时，SRC也能弥补一些我们主动做的，但是防护措施不到位的情况，最大程度地借助社区和圈子的力量，共同保障企业网站、信息和数据的安全。
+
+上述我们提到的很多检测和限制规则，都会通过规则平台沉淀下来，这个就类似于我们的之前讲到的配置管理。
+
+最后，以一张图作为总结，来整体呈现我们的安全体系。也欢迎你给我留言继续讨论。
+
+
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/32为什么蘑菇街会选择上云？是被动选择还是主动出击？.md

@@ -0,0 +1,129 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            32 为什么蘑菇街会选择上云？是被动选择还是主动出击？
+                            2018年1月22日凌晨，我们美丽联合集团旗下的蘑菇街和美丽说的业务，整体搬迁到腾讯云，完成了从托管IDC模式，到腾讯云上混合云模式的转变。
+
+云计算发展到今天，无论是在技术、服务层面，还是在商业层面都已经相对比较成熟。当前绝大多数初创公司在基础设施上的策略一定是公有云，已经极少再有自建或托管IDC的情况，所以不会存在是否上云这样的纠结。
+
+但是对于蘑菇街这样体量的公司，搬迁上云，就必须要考虑得更全面：考虑基础设施的变化，业务的平稳过度，运维模式的转变，成本管控的调整，以及众多的细节问题。
+
+最近，有很多同行对我们为什么做这个选择比较感兴趣。因为尽管混合云模式是当下的大趋势，但真正面临抉择时，又总会被各种具体的细节问题所困扰，犹豫不决。
+
+今天，我从蘑菇街的视角，结合真实情况，聊一聊我们为什么会做出上云这个选择。
+
+我们所面临的问题
+
+1.成本闲置问题
+
+对于电商，大促已经常态化，除了“双11”“双12”以及“6·18”这样的例行大促，每个电商还会有自己的营销活动，比如我们就会有“3·21”春季促销，以及每个月不同的主题促销。这一点对于其它电商也是如此。
+
+大促，从技术层面就意味着要在短时间内应对远远超过日常的峰值流量，可能是平时的十几倍，甚至是上百倍。为了支撑这么大的流量，就需要业务系统有足够的容量支持。
+
+虽然我们会从技术和架构层面来提升容量，但是，无论如何优化，充足的硬件资源扩容是前提条件。
+
+之前，我们在应对“双11”这样的大促时，只能采购更多的设备。与此同时，我们还要在机柜成本以及资源上下架等纯人工方面进行投入，这往往要花费几千万元的成本。
+
+但是，每次大促峰值一过，这些设备基本就处于极低的负载状态。这批资源要经过将近一年时间，随着业务量快速增长才能逐步消化掉，然后再进入到下一轮大促的采购周期中。
+
+所以，这部分成本投入的收益是非常低的，基本处于闲置状态。
+
+2.基础设施维护问题
+
+选择租用或托管IDC模式，随着业务量增长也会遇到一系列的问题。在我以往的实践操作中，我也遇到了以下几个问题，相信你也有过相似的困扰。
+
+IDC机房的选址。在中国互联网八大节点所在城市的IDC资源无疑是最优的，但是这些地方的优质资源却也是最紧张的。通常会被国内各大互联网公司或云计算公司提前占据，所以很难找到相对独立且成规模的机柜区域，而零散的机柜分布对管理和维护工作来说十分不便。
+
+退而求其次，就只能选择二级或三级节点，但是这样一来在网络质量上就降了一个或多个等级。同时，因为没有BGP线路，或者线路质量不高，就需要多线接入，这对业务体验以及管理维护都会带来很大影响。
+
+IDC机房的扩展问题。一个机房内的机柜消耗完，想扩展就只能另找机房，但是属于同一运营商，或同一ISP服务商的同城机房资源是否充足，又是一个未知数。
+
+不同机房间是否互联互通，以及是否增加跨地域的时延，对业务访问体验的影响很大。所以扩展性不足，会大大影响业务体验，甚至影响业务发展。
+
+如果是通过第三方ISP接入的，特别是存在多个ISP服务商的时候，在互联互通时，服务商之间的沟通协调非常耗费精力，且不同机房以及多ISP之间的专线成本也会增加。当基础设施达到一定体量，这个问题会非常突出。
+
+如果你也有过这方面的经历，相信你一定深有体会。
+
+资源利用率问题。即使我们做了虚拟化，按照业界实际情况，CPU资源使用率一般也就在10%-15%左右。所以要想大幅提升使用率，就是要在离线的混部，也就是类似大数据消耗资源特别高的计算类业务上进行资源调配：比如，在凌晨调度到相对空闲的应用服务器上；而在白天，则将资源释放出来给业务应用。
+
+但是，想要在离线混部技术上做文章，说起来容易做起来难，因为这在实际工作中是需要非常深厚的技术积累和非常高的技术门槛的。
+
+业务层面的调度是一方面，另一方面，底层硬件、网络以及操作系统这些也需要相应的技术支持。这其中具体的复杂情况，你可以通过阿里最近在这方面的一些分享体会一下。
+
+单考虑操作系统之上的应用和业务技术是无法满足要求的，所以，这就需要我们在进行技术规划时，在开始底层建设之前就要考虑全面。
+
+我们知道，国内外超大型的互联网公司，以及各大云计算公司，在硬件选型上都有自己的定制化要求。其中一个重要原因，就是为了尽量保持几万甚至十几万硬件设备的系统架构一致，从底层硬件开始就为后续的超大规模运维做技术准备。
+
+当然，这样的定制化需求，只有在需求量足够大的情况下才会被硬件厂商接受，一般如果只有百台或千台的规模，硬件厂商基本是不会考虑的。
+
+所以这就会牵扯出下面这个问题。
+
+3.底层技术投入和人才的问题
+
+通常在互联网领域，越是底层的技术，技术门槛就越高、越复杂，也越离不开高端人才的投入。比如硬件资源虚拟化，就需要有懂内核、懂网络、懂OpenStack、懂分布式存储如Ceph等等的专业人才。
+
+但是真正精通的人却不多，加上要搞定整套解决方案，还需要一个完整的团队，这就难上加难，在团队组建上面临更大的困难。
+
+人才紧缺，就意味着人力成本会很高，这个就是技术投入的隐性成本。而且因为技术门槛高，一旦发生人员流动，那么，对于原有技术平台来说，无人能把控的风险就会更高。这一点往往会是最大的隐性管理成本所在。
+
+当然，在人才招揽上，我们可以加大人力成本投入，招聘最优秀的人才。但是作为像蘑菇街和美丽说这样以更加聚焦于业务，以业务发展为生命线的公司，我们更期望能够在业务上取得创新和发展，而不是在技术上取得多么非凡的成就（这一点与公司的发展诉求是不一致的）。所以这就从根本上决定了，我们不会无限度地投入，或投入非常大的成本在这些基础技术的研究上。
+
+对于以技术创业为主的公司，其考量的出发点就完全不同了，这里我们不展开讨论。
+
+进一步讲，论体量和规模，我们自有的底层技术无论如何是无法与专业的云计算公司相比的，这就带来另一个问题：如何为这些优秀人才提供成长和发展？因为既然在体量和规模上比不过，那我们能够提供的个人成长空间和机会，一定也比不过专业云计算公司。这种情况下，大部分人才的去向选择就显而易见了。
+
+对于大数据，分布式中间件等岗位，也会存在类似的情况，因为它们大多需要体量和规模才能体现技术挑战性和成长空间。
+
+4.小结
+
+到这里我们做个小结，随着基础设施体量越来越大，我们在基础设施和平台服务层面，将会投入越来越大的财力、人力和最宝贵的精力。
+
+但是这项投入的收益和成效却不明显，且在这个层面的专业性上，我们与云计算平台之间的差距越来越大，脱节也越来越严重。
+
+我们的决策过程就是，以未来3-5年，甚至更长远的视角考量，我们认为上述这些问题一定会成为我们将来业务发展的障碍，因此上云就成了我们的不二选择，并成为公司的战略决策之一。
+
+纵观技术发展趋势
+
+1.从软件架构发展的趋势上看，从最早期的物理机，到目前主流的虚拟机，再到当前非常火热的Docker，以及可能在未来会成为又一主流的Serverless，我们对于资源层面的依赖越来越少，而这个趋势恰恰是云计算不断发展带来的改变。
+
+
+
+同时，像Serverless这样的技术理念，就是在公有云平台上，为了提升资源利用率，而衍生出来的。而且从目前看，Serverless也只有在公有云平台上才有意义。在私有云，或者是自建或托管IDC中，因为资源规模问题，没有看到太多的实践价值。
+
+2017年AWS re:Invent 2017峰会上，AWS共发布了在数据库、容器、人工智能、物联网以及网络等等方面的几十项新的产品技术服务。可以说，如果想要技术为业务带来更多的可能性，拥抱云计算是最好的选择。
+
+2.人工智能对云计算能力的释放。我们当前的人工智能主要是对机器学习算法的广泛应用，这里的两个前提条件，一个是要有足够大的数据量，另一个就是要有足够充足的计算资源。
+
+我们先看一个2017年的新闻：
+
+
+2017年5月份，谷歌宣布麻省理工学院的数学教授安德鲁·V·萨瑟兰使用抢占式虚拟机实例，在220000个GCE核心上运行了庞大的数学工作负载。据称这是迄今为止在公共云上运行的最庞大的高性能计算集群。
+
+
+计算任务阶段性的运行对资源需求是非常庞大的，一般企业很难提前预留足够的资源来做这个事情，这时云的资源优势和弹性能力就凸显出来了。
+
+可以说，未来人工智能的发展和应用，必然会依托于云计算。
+
+没有银弹
+
+软件工程中，我们一直在讲，没有银弹。前面我们介绍了我们遇到的一些具体问题，以及云计算的优势所在，但是没有银弹这条规律，仍然也适用于云计算行业。
+
+那么，是不是有了云计算，有了公有云，上述我们所说的问题就都不存在了呢？
+
+以公有云为例，它也一样会遇到IDC建设、扩展性以及基础技术投入等等问题，可能也会给我们带来一定的影响。但是对于公有云来说，因为自身财力和人力的优势，面对这样的问题会更容易解决一些，但对于我们可能就是难以逾越的难题了。
+
+同时，公有云虽然解决了很多问题，但是，就目前这个阶段来讲，如果想要获得较高的客户满意度，仍然有很长的路要走，比如不同形态业务的差异化支持和服务问题。
+
+我想，这一点并不是云计算厂商不想做好，因为无论在技术、产品以及服务上，它们并不是一蹴而就的，而是各方面都需要一个逐步积累、磨合和摸索的过程，这就需要云计算厂商与业务客户共同努力，朝着同一个目标前进，需要彼此多一些耐心。
+
+我们也期望在国内见到AWS和Netflix这样的最佳组合，相互成就，共同成功。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/33为什么混合云是未来云计算的主流形态？.md

@@ -0,0 +1,129 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            33 为什么混合云是未来云计算的主流形态？
+                            2018年1月22日凌晨，我们美丽联合集团旗下的蘑菇街和美丽说的业务，整体搬迁到腾讯云，完成了从托管IDC模式，到腾讯云上混合云模式的转变。
+
+云计算发展到今天，无论是在技术、服务层面，还是在商业层面都已经相对比较成熟。当前绝大多数初创公司在基础设施上的策略一定是公有云，已经极少再有自建或托管IDC的情况，所以不会存在是否上云这样的纠结。
+
+但是对于蘑菇街这样体量的公司，搬迁上云，就必须要考虑得更全面：考虑基础设施的变化，业务的平稳过度，运维模式的转变，成本管控的调整，以及众多的细节问题。
+
+最近，有很多同行对我们为什么做这个选择比较感兴趣。因为尽管混合云模式是当下的大趋势，但真正面临抉择时，又总会被各种具体的细节问题所困扰，犹豫不决。
+
+今天，我从蘑菇街的视角，结合真实情况，聊一聊我们为什么会做出上云这个选择。
+
+我们所面临的问题
+
+1.成本闲置问题
+
+对于电商，大促已经常态化，除了“双11”“双12”以及“6·18”这样的例行大促，每个电商还会有自己的营销活动，比如我们就会有“3·21”春季促销，以及每个月不同的主题促销。这一点对于其它电商也是如此。
+
+大促，从技术层面就意味着要在短时间内应对远远超过日常的峰值流量，可能是平时的十几倍，甚至是上百倍。为了支撑这么大的流量，就需要业务系统有足够的容量支持。
+
+虽然我们会从技术和架构层面来提升容量，但是，无论如何优化，充足的硬件资源扩容是前提条件。
+
+之前，我们在应对“双11”这样的大促时，只能采购更多的设备。与此同时，我们还要在机柜成本以及资源上下架等纯人工方面进行投入，这往往要花费几千万元的成本。
+
+但是，每次大促峰值一过，这些设备基本就处于极低的负载状态。这批资源要经过将近一年时间，随着业务量快速增长才能逐步消化掉，然后再进入到下一轮大促的采购周期中。
+
+所以，这部分成本投入的收益是非常低的，基本处于闲置状态。
+
+2.基础设施维护问题
+
+选择租用或托管IDC模式，随着业务量增长也会遇到一系列的问题。在我以往的实践操作中，我也遇到了以下几个问题，相信你也有过相似的困扰。
+
+IDC机房的选址。在中国互联网八大节点所在城市的IDC资源无疑是最优的，但是这些地方的优质资源却也是最紧张的。通常会被国内各大互联网公司或云计算公司提前占据，所以很难找到相对独立且成规模的机柜区域，而零散的机柜分布对管理和维护工作来说十分不便。
+
+退而求其次，就只能选择二级或三级节点，但是这样一来在网络质量上就降了一个或多个等级。同时，因为没有BGP线路，或者线路质量不高，就需要多线接入，这对业务体验以及管理维护都会带来很大影响。
+
+IDC机房的扩展问题。一个机房内的机柜消耗完，想扩展就只能另找机房，但是属于同一运营商，或同一ISP服务商的同城机房资源是否充足，又是一个未知数。
+
+不同机房间是否互联互通，以及是否增加跨地域的时延，对业务访问体验的影响很大。所以扩展性不足，会大大影响业务体验，甚至影响业务发展。
+
+如果是通过第三方ISP接入的，特别是存在多个ISP服务商的时候，在互联互通时，服务商之间的沟通协调非常耗费精力，且不同机房以及多ISP之间的专线成本也会增加。当基础设施达到一定体量，这个问题会非常突出。
+
+如果你也有过这方面的经历，相信你一定深有体会。
+
+资源利用率问题。即使我们做了虚拟化，按照业界实际情况，CPU资源使用率一般也就在10%-15%左右。所以要想大幅提升使用率，就是要在离线的混部，也就是类似大数据消耗资源特别高的计算类业务上进行资源调配：比如，在凌晨调度到相对空闲的应用服务器上；而在白天，则将资源释放出来给业务应用。
+
+但是，想要在离线混部技术上做文章，说起来容易做起来难，因为这在实际工作中是需要非常深厚的技术积累和非常高的技术门槛的。
+
+业务层面的调度是一方面，另一方面，底层硬件、网络以及操作系统这些也需要相应的技术支持。这其中具体的复杂情况，你可以通过阿里最近在这方面的一些分享体会一下。
+
+单考虑操作系统之上的应用和业务技术是无法满足要求的，所以，这就需要我们在进行技术规划时，在开始底层建设之前就要考虑全面。
+
+我们知道，国内外超大型的互联网公司，以及各大云计算公司，在硬件选型上都有自己的定制化要求。其中一个重要原因，就是为了尽量保持几万甚至十几万硬件设备的系统架构一致，从底层硬件开始就为后续的超大规模运维做技术准备。
+
+当然，这样的定制化需求，只有在需求量足够大的情况下才会被硬件厂商接受，一般如果只有百台或千台的规模，硬件厂商基本是不会考虑的。
+
+所以这就会牵扯出下面这个问题。
+
+3.底层技术投入和人才的问题
+
+通常在互联网领域，越是底层的技术，技术门槛就越高、越复杂，也越离不开高端人才的投入。比如硬件资源虚拟化，就需要有懂内核、懂网络、懂OpenStack、懂分布式存储如Ceph等等的专业人才。
+
+但是真正精通的人却不多，加上要搞定整套解决方案，还需要一个完整的团队，这就难上加难，在团队组建上面临更大的困难。
+
+人才紧缺，就意味着人力成本会很高，这个就是技术投入的隐性成本。而且因为技术门槛高，一旦发生人员流动，那么，对于原有技术平台来说，无人能把控的风险就会更高。这一点往往会是最大的隐性管理成本所在。
+
+当然，在人才招揽上，我们可以加大人力成本投入，招聘最优秀的人才。但是作为像蘑菇街和美丽说这样以更加聚焦于业务，以业务发展为生命线的公司，我们更期望能够在业务上取得创新和发展，而不是在技术上取得多么非凡的成就（这一点与公司的发展诉求是不一致的）。所以这就从根本上决定了，我们不会无限度地投入，或投入非常大的成本在这些基础技术的研究上。
+
+对于以技术创业为主的公司，其考量的出发点就完全不同了，这里我们不展开讨论。
+
+进一步讲，论体量和规模，我们自有的底层技术无论如何是无法与专业的云计算公司相比的，这就带来另一个问题：如何为这些优秀人才提供成长和发展？因为既然在体量和规模上比不过，那我们能够提供的个人成长空间和机会，一定也比不过专业云计算公司。这种情况下，大部分人才的去向选择就显而易见了。
+
+对于大数据，分布式中间件等岗位，也会存在类似的情况，因为它们大多需要体量和规模才能体现技术挑战性和成长空间。
+
+4.小结
+
+到这里我们做个小结，随着基础设施体量越来越大，我们在基础设施和平台服务层面，将会投入越来越大的财力、人力和最宝贵的精力。
+
+但是这项投入的收益和成效却不明显，且在这个层面的专业性上，我们与云计算平台之间的差距越来越大，脱节也越来越严重。
+
+我们的决策过程就是，以未来3-5年，甚至更长远的视角考量，我们认为上述这些问题一定会成为我们将来业务发展的障碍，因此上云就成了我们的不二选择，并成为公司的战略决策之一。
+
+纵观技术发展趋势
+
+1.从软件架构发展的趋势上看，从最早期的物理机，到目前主流的虚拟机，再到当前非常火热的Docker，以及可能在未来会成为又一主流的Serverless，我们对于资源层面的依赖越来越少，而这个趋势恰恰是云计算不断发展带来的改变。
+
+
+
+同时，像Serverless这样的技术理念，就是在公有云平台上，为了提升资源利用率，而衍生出来的。而且从目前看，Serverless也只有在公有云平台上才有意义。在私有云，或者是自建或托管IDC中，因为资源规模问题，没有看到太多的实践价值。
+
+2017年AWS re:Invent 2017峰会上，AWS共发布了在数据库、容器、人工智能、物联网以及网络等等方面的几十项新的产品技术服务。可以说，如果想要技术为业务带来更多的可能性，拥抱云计算是最好的选择。
+
+2.人工智能对云计算能力的释放。我们当前的人工智能主要是对机器学习算法的广泛应用，这里的两个前提条件，一个是要有足够大的数据量，另一个就是要有足够充足的计算资源。
+
+我们先看一个2017年的新闻：
+
+
+2017年5月份，谷歌宣布麻省理工学院的数学教授安德鲁·V·萨瑟兰使用抢占式虚拟机实例，在220000个GCE核心上运行了庞大的数学工作负载。据称这是迄今为止在公共云上运行的最庞大的高性能计算集群。
+
+
+计算任务阶段性的运行对资源需求是非常庞大的，一般企业很难提前预留足够的资源来做这个事情，这时云的资源优势和弹性能力就凸显出来了。
+
+可以说，未来人工智能的发展和应用，必然会依托于云计算。
+
+没有银弹
+
+软件工程中，我们一直在讲，没有银弹。前面我们介绍了我们遇到的一些具体问题，以及云计算的优势所在，但是没有银弹这条规律，仍然也适用于云计算行业。
+
+那么，是不是有了云计算，有了公有云，上述我们所说的问题就都不存在了呢？
+
+以公有云为例，它也一样会遇到IDC建设、扩展性以及基础技术投入等等问题，可能也会给我们带来一定的影响。但是对于公有云来说，因为自身财力和人力的优势，面对这样的问题会更容易解决一些，但对于我们可能就是难以逾越的难题了。
+
+同时，公有云虽然解决了很多问题，但是，就目前这个阶段来讲，如果想要获得较高的客户满意度，仍然有很长的路要走，比如不同形态业务的差异化支持和服务问题。
+
+我想，这一点并不是云计算厂商不想做好，因为无论在技术、产品以及服务上，它们并不是一蹴而就的，而是各方面都需要一个逐步积累、磨合和摸索的过程，这就需要云计算厂商与业务客户共同努力，朝着同一个目标前进，需要彼此多一些耐心。
+
+我们也期望在国内见到AWS和Netflix这样的最佳组合，相互成就，共同成功。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/35以绝对优势立足：从CDN和云存储来聊聊云生态的崛起.md

@@ -0,0 +1,99 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            35 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起
+                            前面几期文章我们介绍了混合云模式，以及面向应用层的云架构解决方案的Spring Cloud。接下来，我们就以蘑菇街的两个具体案例，来分享一下基于混合云模式的具体实践。
+
+今天，我们先一起看一下我们最为熟悉的CDN和云存储建设。
+
+CDN和云存储
+
+我们之前提到，CDN应该算是最早期、最典型的公有云服务，如果我们在业务上用到了CDN服务，其实就已经算是在实践混合云模式了。
+
+蘑菇街作为ToC的电商业务，自然会有大量的图片访问需求，其中尤以商品图片为最。为了保证用户体验，我们的产品在2011年上线之初，就应用了CDN技术，当时我们合作的都是专业的CDN厂商。
+
+当然，大量的图片访问需求会带来大量的图片存储需求，且随着业务高速发展，这个需求量必然会极速增长。
+
+图片的访问需求量往往会以几百万、几千万、几亿到几十亿、上百亿的增长态势呈现。而它所占用的存储空间也会从G扩展到T，到几十T、几百T，再到后来的P级别。
+
+所以，起初我们在业务量不大的时候，还可以把图片存在自己的硬件设备上。再往后可以利用HDFS这样的对象存储技术来实现，CDN回源的请求全部回到我们自己的机房里。
+
+但是再往后，我们在这方面的专业性就不够了。这也是我在[《为什么蘑菇街会选择上云？是被动选择还是主动出击？》]一文中介绍到的：随着体量的增加，CDN对于专业技术深度的要求就越来越高，技术层面的投入也会越来越大，这个就与我们的业务发展诉求不一致了。
+
+因为对于蘑菇街来说，我们还是期望能够把更多的人力和物力应用到业务技术层面，而不是一味耗费在专业技术研究上。
+
+在2013年左右，业界开始出现专业的云存储厂商。在专业技术层面要比我们精深很多，而且他们聚拢了一大批业界专业人才，积累了各类海量存储场景的实践经验，所以他们在产品研发和服务支持上也是能够持续深入的。
+
+基于此，我们后来就选择了将海量的图片放到专业性更强的云存储之上。
+
+到这个阶段，我们的图片访问和图片存储就近乎完全依赖外部第三方的服务，同时也形成了CDN回源访问云存储这样的云应用模式。
+
+再往后发展，随着国内两大公有云巨头腾讯云和阿里云相继杀入CDN市场，这对传统的CDN厂商和新兴的云存储业务造成了很大的冲击。但究其主要原因，我认为还是由于云生态的规模优势发挥了作用。
+
+云生态的优势
+
+上面讲到，我们使用的CDN是专业的CDN厂商业务，但在当时它们并不提供云存储业务。
+
+同时，专业的云存储厂商固然在存储技术上更擅长，加上它们大多属于创业公司，也没有太多的财力和人力再杀入CDN市场。
+
+所以，这两块紧耦合的业务实际是由两类不同的公司在独立发展。但是，在阿里云和腾讯云这样的公有云巨头进入市场后，就极大地改变了这样一个格局。
+
+因为阿里和腾讯各自都有遍布全球的超大规模的自有业务，在CDN、存储技术以及资源上也有很深厚的积累。当公有云蓬勃发展起来之后，这样的技术和资源积累就可以从内部通过云平台输出给公有云的用户。
+
+那么，阿里云和腾讯云这种公有云模式有哪些优势呢？我们将CDN模式与其对比来看。
+
+1.技术层面。CDN模式下，图片上传云存储以及CDN回源云存储，基本都是走公网网络，在国内复杂的网络条件下，传输质量就很难保障。
+
+我记得2015年我来到蘑菇街接手运维的时候，就经常会遇到网站图片展示不出来或者打开特别慢的情况。这就需要找不同的CDN厂商定位一些个例问题，非常耗时且麻烦，令人头痛。
+
+在这种形态下，因为是不同厂商间的协作，所以问题只能在小范围内优化，无法从根本上得到改善。但是，在以阿里云和腾讯云为代表的公有云模式下，这个问题就会迎刃而解。
+
+因为阿里和腾讯这两大巨头各自都有全球规模的业务体量，为了保证自身业务的访问体验，它们一定会在CDN和存储技术的优化、整合上下足工夫，因此更具备自我改进的动力。
+
+尤其是上面我们提到的上传和回源过程，在公有云模式下基本都有专线质量保障。即使没有专线，他们也会不断优化中间的线路质量。
+
+上云后我们最明显的感受，就是上传和回源图片的成功率和速度都有非常大的改善，近一年来，我很少再碰到像图片展示慢这类问题了。
+
+2.成本层面。主要包括三块费用：
+
+
+CDN带宽费用。用户访问带来的CDN流量费用，由各CDN厂商收取。对于传统CDN厂商，之前价格相对固定和平稳，但是近两年公有云厂商入局后不断降价，在价格上有非常大的竞争优势，这也整体拉低了CDN价格。
+回源带宽费用。当CDN无法获取到对应图片时，回源到云存储获取，这部分回源带宽费用由云存储厂商收取。但是在云生态模式下，上面提到，CDN和云存储可以整合到某个公有云内部网络体系内，在这个生态中，这部分费用成本就变得非常低了。
+存储空间费用。这一项费用由云存储厂商收取，CDN和公有云这两种模式在这一点上没有太大区别。
+
+
+还有其他诸如裁图、HTTPS等服务，都分别会有不同的计费方式，但是这块不是主要成本。
+
+说到这里，我们从整体的商务角度看一下：如果一位客户在同一个地方购买的服务和资源越多，那么商务运作和议价空间就会越大，得到的优惠力度也会更大。这就跟我们在同一家商店买的东西越多、折扣越多是一个道理。
+
+但是，如果这些服务和资源都是不同厂商的，那就需要多方面沟通。整个过程耗时耗力，且能够得到的优惠空间也非常有限。
+
+所以，整体来看，云生态在CDN和云存储这个层面，实实在在地帮我们降低了成本。
+
+3.生态优势，强者越强。云生态的天然优势在于，云平台上聚集了海量的客户资源，只要进入到这个生态中，一般情况下客户都会首选生态内的产品，而不会再跳出去选择其它独立的产品服务。
+
+甚至即使之前用到了第三方的服务，客户也会逐渐转移回云平台这个生态体系中来。
+
+所以，我们现在可以看到这样一种趋势：很多独立的技术产品，正在向云生态靠拢，选择跟公有云合作，争取让产品进入到某个云生态中，并提供相应的云上解决方案和技术支持。
+
+同时，各大巨头也会寻找在某些特定领域，有相当深度的技术产品进行投资，让这些好的产品和解决方案进入到自己的云生态中，以便进一步为云上的客户提供更全面、灵活和多样性的支持。
+
+总结
+
+通过CDN和云存储这个案例，我们可以清晰地看到，随着公有云的深入发展，特别是公有云巨头的飞速进步，公有云已经形成了自有的、独特的生态体系。
+
+这不仅仅体现在技术和产品层面，而且可以预见其最终还会形成商业层面的体系闭环。
+
+所以，利用云计算的优势，拥抱变化，才能够为我们的业务发展和创新带来更多的可能性。
+
+以上分享的这些内容，是我在近两年的工作中真切经历过的案例和感受，希望能在思路拓展上对你有所帮助。
+
+如果你在这方面有什么好的经验和想法，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/36量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设.md

@@ -0,0 +1,115 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            36 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设
+                            上期文章中我们介绍了CDN和云存储的实践，以及云生态的崛起之路，今天，我们继续聊一聊CDN。
+
+我们通常意义上讲的CDN，更多的是针对静态资源类的内容分发网络，最典型的就是电商的各类图片，还有JS和CSS这样的样式文件。通过CDN能够让用户就近访问，提升用户体验。
+
+但是这类文件只是以单纯的资源存在，与业务逻辑没有强关联。所以我们在技术上，可以使用业界通用的CDN和云存储解决方案。
+
+需要注意的是，本文中我们讲到的实践内容，同样是遵从静态内容，就近访问这个原则的。
+
+但是，因为其中包含了大量的业务逻辑，这就要求我们在面对不同的场景时，要有跟业务逻辑相关的定制化的解决方案。
+
+下面，我们就一起来看看页面静态化架构和二级CDN建设。
+
+静态化架构建设的业务场景
+
+我们仍然回到电商的业务场景中来。对于电商，访问量最大的无疑是商品的详情页，绝大多数用户都要通过浏览商品详情，来决定是否下单。所以单就这一类页面，就占到全站30%+的流量。
+
+那么，商品详情一般由哪些部分组成呢？我们看下面两个截图：
+
+
+
+
+
+以上两张图就是某个商品详情页的主要组成部分。我们可以看到，商品详情大致包括了商品名称、商品描述、产品参数描述、价格、SKU、库存、评价、优惠活动、优惠规则以及同款推荐等等信息。
+
+这里我们仔细观察可以发现，其实对于商品描述类的信息，比如商品名称、商品描述、产品参数描述等等，一般在商品发布之后，就很少再变动，属于静态化的内容。
+
+而优惠活动、优惠规则、价格等等则是可以灵活调整的，库存和评价这类信息也是随时变化，处于不断的更新中。
+
+说到这里，我们会想到，如果能够把静态化的内容提取出来单独存放，业务请求时直接返回，而不用再通过调用应用层接口的方式，去访问缓存或者查询数据库，那访问效率一定是会大幅提升的。
+
+所以，我们在参考和调研了业界的解决方案之后，引入了页面静态化架构。
+
+页面静态化架构
+
+静态架构中，我们采用的技术方案是ATS，也就是Apache Traffic Server。
+
+ATS是一个开源产品，本质上跟Nginx、Squid以及Varnish这样的HTTP反向代理是一样的。但是它能对动静态分离的场景提供很好的支持，所以在最初，我们直接引入了这样的开源解决方案。
+
+ATS的架构示意图如下：
+
+
+
+关键技术点：
+
+
+动静态分离。将页面上相对固定的静态信息和随时在变化的动态信息区分出来，静态信息直接在ATS集群获取，动态信息则回源到应用层。通过HTTP请求调用获取，最终通过ATS组装后返回给调用方，从而实现了动静态资源的分离。
+动态数据获取。直接采用ATS的ESI标签模式，用来标记那些动态的被请求的数据。
+失效机制。分为主动失效、被动失效和定时失效。对于静态信息来说，我们也允许它变化，但因为静态信息自身的特性，决定了它不会频繁变化。所以，我们会有一个失效中心，即Purge Center。失效消息通过HTTP的Purge方法发送给ATS，而失效中心则会通过订阅消息系统中特定的Topic，或者MySql中特定的binlong变更，执行失效。
+
+
+以上就是静态化建设的框架性的解决方案，这个方案在电商大促时往往能够发挥更加突出的作用。下面我就简单说明下。
+
+静态化架构在大促场景中的应用
+
+我们还是以业务场景作为切入点来看。以“双11”为例，参与大促的商家和商品，一般会在11月初完成全部报名。届时所有的商品信息都将确认完毕，且直到“双11活动”结束，基本不会再发生大的变化。
+
+它跟平时的不同之处在于，商品在大促期间是相对固定的，所以就可以将商品的静态化信息提前预热到ATS集群中，大大提升静态化的命中率。
+
+同时，价格、优惠、库存这些动态信息在日常是会经常变化的，但是在大促阶段是必须固定的。即使有变化，也只能体现在最终的订购阶段，而在用户浏览阶段尽量保持不变。
+
+所以，这时可做静态化处理的内容就会更多。换言之，静态化架构对于后端的访问请求就会进一步减少，特别是价格、优惠和库存这样的查询计算类请求。
+
+同时，我们静态化页面的范围可以更广，不仅仅是详情页，还可以包括各类大促活动的页面、秒杀页面、会场页面，甚至是首页。
+
+因为这些页面都是提前配置好再发布的，所以我们完全可以通过静态化解决方案，来分担更大的流量。
+
+以详情页为例。在静态化方案全面铺开推广后，静态化内容在大促阶段的命中率为95%，RT时延从原来完全动态获取的200ms，降低到50ms。这大大提升了用户体验，同时也大幅提升了整体系统容量。
+
+静态化方案和应用场景我们就介绍到这里。你可能会问：既然是静态化的内容，那是不是仍然可以借鉴CDN的思路，让用户就近访问呢？
+
+我们下面就介绍一下页面静态化与公有云相结合的方案：二级CDN建设。
+
+二级CDN建设
+
+上面我们提到的静态化方案，仅仅是我们自己中心机房的建设方案，也就是说，所有的用户请求还是都要回到中心机房中。
+
+静态化方案提升的是后端的访问体验，但是用户到机房的这段距离的体验并没有改善。
+
+从静态化的角度，这些内容我们完全可以分散到更多的地域节点上，让它们离用户更近，从而真正解决从用户起点到机房终点的距离问题。
+
+所以，我们接下来的方案就是：选择公有云节点，进行静态化与公有云相结合的方案，也就是我们的二级CDN方案。简单示意如下：
+
+
+
+引入了这样的二级CDN架构后，下面几个技术点需要我们多加关注。
+
+
+回源线路，公网回源转变为专线回源。之前我们的中心机房还是托管IDC模式时，动态回源部分都是通过公网回源，同时，静态化配置的推送也是通过公网推送到公有云节点，这对成功率和访问质量上都会有一些影响。但是我们上云之后，做的第一件事情就是将公网访问模式调整成了内网调用模式，也就是动态回源直接改为专线的动态回源。这样大大提升了访问质量，且进一步节省了部分带宽费用。
+弹性伸缩。利用了公有云节点之后，在大促时就可以很方便地进行动态扩缩容，以便真正地按需使用。而且自动化的扩缩容，以及日常的静态化配置推送都需要完善。
+高可用保障。为了保障多节点的高可用，在单个节点故障时，要能够快速切换。当前我们的策略仍然是，当某个节点遭遇故障，直接全部切换回中心节点。这里为了能够达到快速切换的目的，需要通过HttpDNS这样切换IP的方式实现。因为DNS缓存生效周期较长，如果是通过域名切换，则造成的影响周期会比较长。
+
+
+总结
+
+今天分享的页面静态化架构方案和二级CDN方案，是我在实际工作中较早跟公有云方案相结合的实践之一，并且在我们的日常和大促活动中，起到了非常好的效果。
+
+同时也可以看到，我们的业务一旦与公有云相结合，云生态的各种优势就会马上体现出来。但是无论选择哪种方案，都要结合具体的业务场景，才能作出最优的方案选择。
+
+公有云也好，云计算也好，都不能为我们提供完美的定制解决方案。正所谓具体问题具体分析，找出问题，优化解决路径，量体裁衣，才能得到最适合我们的“定制方案”。
+
+正如我之前提到的：只有挖掘出对业务有价值的东西，我们的技术才会有创新，才会有生命力。
+
+如果你在这方面有好的实践经验和想法，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/37云计算时代，我们所说的弹性伸缩，弹的到底是什么？.md

@@ -0,0 +1,57 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            37 云计算时代，我们所说的弹性伸缩，弹的到底是什么？
+                            现在，我们经常听到的一些高大上的词汇，比如弹性伸缩、水平扩展和自动化扩缩容等等，你能否说一说，这些技术手段的主体是谁，也就是谁的水平扩展？弹性伸缩的是什么？同时，这些名词之间又有什么关系呢？
+
+下面我们就从弹性伸缩入手一起来分析讨论。
+
+弹性伸缩的主体是谁？
+
+弹性伸缩，一说到这个词，我们可能很自然地会联想到资源的弹性伸缩，服务器的弹性伸缩，容量的弹性伸缩，应用的弹性伸缩以及业务的弹性伸缩等等。我想这些理解都没有错误，但是可以发现，当弹性伸缩这个动词前面增加了这么多不同的主语之后，我们一下子就不知道到底该做什么了。
+
+其实有这样的困惑很正常。我们在讲标准化的时候就提到，做运维和做架构的思路是相通的，我们碰到问题后，一定要找到问题的主体是什么，通过问题找主体，通过主体的特性制定问题的解决方案。
+
+对于运维，一定要准确识别出日常运维过程中不同的运维对象，然后再进一步去分析这个对象所对应的运维场景是什么，进而才是针对运维场景的分解和开发。
+
+这里可以看到，弹性伸缩其实是一个运维场景，但是我们并没有定义这个场景的主体是谁，所以就会出现上面这些不同的主体。我们来假设以下几种主体。
+
+
+服务器的弹性伸缩。针对这个场景，假设业务是运行在私有云或公有云上，那我们只要能够通过云平台的API申请和释放资源，申请时初始化我们的操作系统，释放时销毁资源就可以。不过，在私有云环境下，为了能够保障弹性，我们必须自己提前采购、上架、装机、配置然后交付资源，需要大量的准备工作，公有云上就可以省去这些步骤，可以即拿即用。
+应用的弹性伸缩。这个场景下其实是默认包含第一步的，就是我们首先必须要拿到应用运行的服务器资源才可以，这一步做到了，下面就是应用的部署、启动以及服务上线接入流量。
+业务的弹性伸缩。我们可以再进一步思考，通常一个业务可能会包括多个应用，所以为了保障整个业务容量充足，这个时候扩容单个的应用是没有意义的，所以这时要做的就是扩容多个应用，但是这里面就会有一个顺序问题，先扩哪个，后扩哪个，哪些又是可以同时扩容而不会影响业务正常运行的，再进一步，业务承载的服务能力提升了，那网络带宽、缓存、DB等等这些基础设施需不需要也同时扩容呢？
+
+
+到这里，这个问题就已经变得非常复杂了，而且已经不仅仅是弹性伸缩这个词的表面含义所能覆盖的了，因为这个问题确实很复杂，所以这里暂时不做详述。
+
+好了，分析到这里，我们就可以看到针对不同的运维对象，弹性伸缩这个概念背后的含义是不一样的，所执行的动作以及制定的方案也是不一样的。通过上面的分析过程，我们在日常思考和工作开展中应该注意以下两点。
+
+第一，一定是从实际问题出发，找到问题的主体，然后才是针对问题的解决方案。要反复问自己和团队，我们解决的问题是什么？解决的是谁的问题？切记，一定不要拿着解决方案来找问题，甚至是制造问题。
+
+比如弹性伸缩这个概念，它就是解决方案，而不是问题本身，问题应该是：业务服务能力不足时，如何快速扩容？业务服务能力冗余时，如何释放资源，节省成本？按照这个思路来，我们自然就提炼出业务服务能力这个主体，面对的场景是快速的扩缩容，然后针对场景进一步细化和分解。
+
+第二，如果问题处于初期，且是发散状态时，主体可能表现出很多个，这时我们一定要找到最本质的那一个，往往这个主体所涉及的运维场景就包括了其它主体的场景。
+
+比如上面我们看到的业务的弹性伸缩，就包含了应用和服务器的弹性伸缩场景，它们只不过是子场景而已。从这个角度出发，我们的思路才能打开，方案才会全面。不然如果只是聚焦在服务器、应用、DB、网络等等这些非本质的主体上，提供出来的解决方案肯定也是片面的，而且经常会出现这样的情况，每个人都只从自己的角度出发说问题，始终无法达成一致。问题的根本还是我们没有一个共同讨论的基础，结果就是工作没少做，却始终没有解决问题。
+
+弹性伸缩、水平扩展和自动化扩缩容，它们之间的关系是什么？
+
+这个问题，我想已经不言自明了，找到它们的主体和要解决的问题，我们就会发现，其实它们之间的含义是一样的。
+
+总结
+
+今天我们以弹性伸缩为例，讨论了如何思考问题和分析问题。我们的讨论和分析归结到一点就是：独立思考和分析的能力很重要，意识也很重要，切忌不可人云亦云随大流，反而迷失了工作的方向。
+
+现在业界各种技术上的Buzzword（时髦词）层出不穷，让人目不暇接，但是仔细观察和思考，你会发现它们背后常常隐藏着很多共性的特点，一定要抓住它们背后所要解决的问题和本质，这样也就不会乱花渐欲迷人眼了。
+
+而且通过这样的分析，我们会更容易发现工作中还需完善的地方，从而引导我们聚焦到实际问题中来，而不是浮于表面，把一些高大上的词汇挂在嘴边，却不见效果。
+
+关于今天我们讨论的主题，你还有哪些想法和心得，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/38我是如何走上运维岗位的？.md

@@ -0,0 +1,114 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            38 我是如何走上运维岗位的？
+                            在专栏介绍中，我简单分享了自己为什么会走上运维这个岗位，一是责任心使然，出现问题时总是会主动冲在前面解决，另一个是在这个过程中技能提升得很快，很有成就感。不过当时受篇幅所限，并没有完整说明，所以今天我想再来聊一聊这个话题。
+
+聊这个话题还有一个出发点，就是当下业界对运维的认知和定位还是存在很多问题的，有不少贬低运维的言论，所以我想结合自己的经历谈谈对这个事情的看法，期望能够带给你一些启发。
+
+我是怎么开始做运维工作的？
+
+我做运维是在加入华为1年后开始的。在华为内部，我从来没有听说过任何贬低运维的说法，反倒是从华为出来，才开始听到一些言论，比如运维背锅、运维层次低等等，当时感觉还有点怪怪的，这一点下面会再详细讲到。
+
+我当时是在华为电信软件部门，大家熟知的短信、彩信、智能网、BOSS计费系统以及运营商客服系统等都是这个部门的产品。我到公司没多久就进入了一个新成立的项目组，为运营商开发一个阅读类互联网产品，因为是工作后参与的第一个正式项目，从需求讨论、方案选型、代码开发到上线这样一路跟来下，几乎倾注了我所有的热情。当时完全是封闭式开发，除了吃饭睡觉，其它时间基本都用在这个项目上，周六日都是泡在公司的。
+
+项目上线之后，基于运营商海量用户的积累，业务量很快就增长上来了，按照惯例，各种系统问题、故障宕机也随之而来了。当时我们团队规模不大，大家也都是齐心协力，出现问题我们总是一群人一起冲上去解决问题。之所以有这样的反应，主要是因为不忍心看到自己和团队一手打造出来的系统出问题。在华为，软件质量的荣誉感胜过一切。
+
+因为我经验尚浅，所以一开始都是跟在后面看着主管和老员工解决，后来对于一些疑难问题，我就会主动要求接过来研究一下，有时候一个问题要研究好几天才会有些眉目，不过也是在这样的一个过程中，随着解决的问题越来越多，经验也就越来越丰富，很快就成长了起来。
+
+再加上我一直是出现问题后，第一个做出响应和冲到最前面的那个人，主管和团队也对我有了足够的信任和认可，也正是因为获得了这样的信任和认可，后来我得到的成长机会就越来越多。
+
+这里就分享一点：
+
+
+要敢于承担责任，敢于表达自己的想法。特别是对于职场新人，只有承担，且敢于承担更多更重要的责任，才能够快速成长起来。一些重要事项，主管肯定是优先安排最稳妥和靠谱的人去做，这个时候老员工的优势会更明显，作为新人或经验尚浅的员工，如果没有积极主动的态度和令人放心的表现，很多好机会往往就与你失之交臂了。
+
+
+当时，我们解决完问题，不仅仅是内部解决完就好了，还要给客户汇报。说简单点，就是把问题原因、处理过程和后续改进措施，用客户能够听懂的表达方式讲出来。一般都是先用邮件发送正式的报告，然后再当面做解释和汇报。当客户不理解、不认可的时候，你就要花更多的时间和精力想办法去表达清楚。
+
+说实话，我当时认为这是非常浪费时间的事情，我想要是把这些时间都花在技术研发上该多好。不过，多年以后回过头来看，这个过程对于培养、提升自己的“软技能”是很有帮助的，主要锻炼了以下几个能力。
+
+
+能站在对方的角度考虑问题，或者说要有服务心态。很简单的一点，你不能拿着一堆晦涩难懂的技术术语去给客户解释，而是得用客户听得懂的业务语言解释。
+文字表达和口头表达能力。不论是书面的还是口头的，表达一件事情都要有清晰的逻辑，把前因后果理顺畅，先有结论，然后分条陈述。我现在能写这么长篇幅的专栏文章，很大程度上也是受益于这个过程中写报告的锻炼。
+从更全面的角度看待问题。有时候有些问题可能不仅仅是技术层面的问题，也可能出在其他方面比如业务逻辑、第三方、用户自身以及信息沟通上。一开始，面对这种问题我都是直接反馈说不是技术问题，跟我们没关系，可以想到这样的回答总是会被客户诟病。慢慢地我才发现，即使问题最终不是由你来解决，也应该全面考虑问题，跟客户一起讨论最终的解决方案，这样才会得到认可。后来我发现这是一个技术人员普遍存在的问题，比如，“我的代码没问题”，“在我的电脑上是好的”等等，其实就是缺乏全面看问题的意识，也是缺少站在对方角度考虑问题的意识。
+首问负责，问题闭环。问题找到你，你就要端到端负责解决，最终要给客户一个满意的答复，即使问题解决不了，也要能够获得客户认可的反馈。而且，如果这个事情是比较复杂的，需要时间和一个过程来解决，一定要在过程中及时反馈，而不是迟迟不响应。一个最常见的反模式就是“这个跟我没关系，你去找谁谁谁吧”，一句话就把客户的满意度给消磨没了。
+
+
+这么多年工作经历下来，我感觉对我个人职业发展帮助最大的，恰恰是上面这些良好的工作习惯，没有这些好习惯的扶持，单纯的技术技能成长很容易遇到瓶颈。而且，如果说技术技能是在不断更迭变化的，上面这些做事的基本原则却可以随时随地迁移使用。趁早养成良好的职业习惯，会对个人发展有巨大的好处。
+
+对这个阶段做个总结，我更愿意承担一些非常具有挑战性的工作，成长得就比较快。同时，在客户层面，我又相对比较愿意表达见解和意见。虽然那个时候没有什么沟通技巧，也没什么表达技巧，甚至有些时候是笨嘴拙舌的，但是，很多时候技巧是次要的，最关键的是要敢于表达，当团队需要这样一个角色时，是不是有人能够站出来承担起这个职责。慢慢地我在客户层面也得到了一定的认可和信任，成为一个真心诚意、关键时刻能靠得住的一个人。通过这样一个阶段，我不但在技能深度上有了积累，在广度上也体现出了明显的优势。
+
+我为什么会把运维当作职业发展的方向？
+
+这个阶段大约也就1年左右，我的主管就开始跟我沟通，由我来组建这个产品的运维团队，把线上运维、稳定性和部分客户沟通工作完全交给我。
+
+可能有些人觉得做运维是很低级的事情，让你做运维就是让你去填坑，其实对于这样的言论以及今天开头提到的什么运维背锅论，我是十分反对的。当然，更多的时候我也不是去解释，而是靠做事情来证明。
+
+说回到当时的事情上，当时主管在跟我沟通独立带一个运维团队时，我的感受不仅仅是晋升层面的喜悦，更多的是因为能够做运维而感到非常自豪。
+
+为什么会非常自豪，这就不得不提到华为内部，在当时来讲，就已经有非常完善和先进的运维体系和运作机制了，我们一起来看一下。
+
+在华为内部，运维是非常受尊重而且非常关键的岗位。如果你在研发团队中一直写代码，没有做过运维工作，是很难晋升高级别岗位的。所以华为的架构师、技术经理甚至是更高级别的研发主管，按照不成文的规定，都默认要在运维团队轮岗过，然后再选拔出来。而且这里面最最关键的是，运维这个岗位不是你想做就能做的，是有条件要求的。
+
+下面我们就来看看有什么样的条件要求。我当时是在华为电信业务软件部，华为的运维体系分为一、二、三线，我们分别来看。
+
+1. 一线维护
+
+这个团队是负责产品的交付服务和后续的客户服务工作。从技能上，很像传统运维，主要是对网络设备、硬件主机和操作系统层面要熟练。一方面要负责交付的项目管理；另一方面，也是非常重要的一点，要对一线客户满意度负责，也就是客户反馈的所有问题，甚至是客户工作中表现出来的喜怒哀乐都要关注。
+
+一线维护，最重要的就是必须要有非常强的服务意识。
+
+2. 二线技术支持
+
+因为一线维护面对的是单个具体的运营商，在遇到一些问题的时候，往往没有经验，但是二线因为要面对某个产品全球的局点问题，所以在经验上更容易沉淀和积累。当某个一线团队遇到没有经验的问题时，二线有可能就可以很快很好地帮忙解决，而不用直接透传到三线。
+
+同时，二线还要做好统筹协调，因为一线过来的问题不仅仅是产品本身问题，也可能是网络设备、硬件、操作系统、存储甚至数据库等的问题，这就需要二线帮助一线协调专家资源进行处理，而不是一线再一个个找人，这时一线只管反馈问题即可。
+
+二线技术支持，大多由产品研发或者一线维护经验的人员抽调上来的，即使没有这些经验，也要下放到一线去锻炼很长时间，两三年都有可能，所以技术和经验上都相对更加全面，同时能够有较强的推进协调能力。
+
+3. 三线研发维优
+
+到了三线就是研发团队中的运维团队了，这个团队在华为叫做维优团队。这个团队就很牛了，一般都是从开发骨干精挑细选出来的，一方面是为了锻炼人，另一方面也是为了在出现问题时，能够有最专业、能力最强的人响应处理，因为电信级业务是国计民生的基础设施，一般传递到三线的问题，都是比较严重或者疑难的了，必须投入精兵强将第一时间解决问题。
+
+处理问题的过程中，还会不断完善工具体系，提升日常维护和问题定位的效率。因为三线同样要面对全球局点问题，所以7*24响应，而且常年无休，比我们现在互联网运维的工作负荷要大得多，所以这个团队成员一般做个1~2年就会转岗晋升，不然身体肯定是承受不住的。
+
+三线研发维优，这个团队的成员就像军队中的突击队或尖刀连一样，总是冲在最前面，在高压状态下，解决最复杂、最棘手的问题，所以从选拔阶段，就有非常高的要求。最终经过这个团队磨练出来的人，技术能力、沟通协作能力以及全面解决问题的能力，都是非常突出的。自然地，在晋升发展方面就会有更大竞争优势。
+
+上述这样一个非常严密的一、二、三线运维机制和协作体系，各条线各司其职，发挥各自优势作用，串联起了客户、产品和研发整个技术支持体系，基本上就支撑起了华为电信软件在全球局点的技术支持和服务工作，这一点还是很强大的。
+
+也因为各自都有独特的价值体现，所以运维岗位上人员的存在感和成就感就会比较强，当然就不会觉得做运维是很低级的事情。同时，因为人员非常优秀，能力突出，这个岗位得到尊重也是必然的，甚至是令人向往的。
+
+其实，能够得到尊重，还有非常重要的一点，就是来自华为对客户和用户的尊重，真正的把“客户第一”融入到了整个公司的组织架构和运作机制中。
+
+这里我们不做过多发散，理解下来就是谁离客户最近，谁对客户负责，谁就能代表客户，谁就有最大的话语权，甚至是指挥权和决策权。体现在上述我们所说的运维机制上，就是：一线的声音，代表了客户声音；一线反馈到二线的问题，二线必须响应；二线传递到三线的问题，三线必须响应。
+
+当然，问题级别不同，响应效率可以不同。同时，三线可以根据客户现场情况，以及问题严重程度，对问题进行升级，以知会到更高层级的主管进行关注。
+
+在考核上，如果一线提交的问题，最终被定性为二线支持问题，或者三线研发质量问题，那二、三线的全年考核将会受到影响，如果是频繁出现问题，那就会受到严重影响，而且各级主管要承担连带责任。
+
+这套机制的根本目的，还是为了促进整个体系能够以尽快解决问题、提升软件质量为目标。整个团队树立起这样的观念，就自然会对质量和问题有敬畏感，研发维优那个时候大多都是远程电话与一、二线沟通，潜意识里就会把一、二线作为他们的客户，同样保持谦卑和尊重。
+
+所以，无论是从对运维的定位上，还是整个公司文化以及运作机制上，都形成了对这个岗位的高度定位和尊重。
+
+说回到我个人，因为当时项目性质的原因（前面提到本质上是一个互联网形态的项目），是高度定制化的，并不是传统电信业务的产品形态，所以当时我们无法直接获得一、二线的支持，所有的运维工作都由研发团队完全独立承担，当时我就是把一、三线的事情都做了，前面很长一段时间是既做开发又做三线维优工作，对我技能上的提升帮助非常大。再往后因为精力有限，在后端维优团队建立起来之后，我就花更多时间做一线工作，贴近客户多一些，这里就对我之前说的职场软技能的提升有很大帮助。
+
+当时华为的三线研发维优，其实很像Google的SRE岗位，各方面能力要求很高，不仅仅是软件开发这么简单，所以当时让我去做运维，并且给到我足够的授权去组建和带团队，就相当于让我去做SRE这样高端的岗位，我自然会觉得非常自豪。
+
+再往后，在这个专业方向上做精做细，形成差异化的优势，自然就会有更大的收获。
+
+给我们的一点启发
+
+这样的一个发展过程并不是我刻意设计过的，机会也不是刻意争取到的，就是平时多做一点，做得认真一点，确保最终能够拿到结果，而且稍微努力一下，尽量拿到比预期好一些的结果。在这个过程中，随着个人能力的提升和全面发展，后续各种机会也就随之而来了。
+
+如果让我总结就是这么平淡无奇，如果让我给出个人发展建议，想要从普通做到优秀的话，就是上面几句话。
+
+岗位上，可能不会跟我一样去做运维，但却一样可以做到优秀的架构师、技术专家、项目经理或产品经理等等，只要你有心即可。
+
+最后，你在个人成长和实际工作中遇到过哪些问题呢，有哪些感悟和心得，欢迎留言和我讨论。如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/39云计算和AI时代，运维应该如何做好转型？.md

@@ -0,0 +1,117 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            39 云计算和AI时代，运维应该如何做好转型？
+                            今天我们来聊一聊，在云计算和AI时代，运维应该如何做好转型？今天的内容可以说是我们前面运维组织架构和协作模式转型的姊妹篇。针对运维转型这个话题，谈谈我的思考和建议。
+
+我们先来看业界的三个典型案例，一个来自国外，一个来自国内，最后一个是我自己团队的案例，都非常具有代表性。
+
+先看国外Netflix的模式。
+
+Netflix从一开始就强调开发人员进行自助化运维。我们第一篇文章中就介绍到，Netflix内部的运维工作全部都由开发人员完成，平台也由开发自己完成，只保留极少的Core SRE角色专门响应和处理严重等级的故障。类似的还有亚马逊，无论是其电商业务，还是AWS公有云服务，全部都由开发搞定。
+
+这样的团队因为其技术前瞻性，微服务以及分布式这样的技术架构早已落地，再加上其超强的技术能力，所以可以从一开始就这样来做。
+
+再看国内阿里的模式。
+
+阿里技术团队在2016年左右，也开始进行“去PE”的组织架构调整，原来需要PE完成的运维工作，全部由开发承担。原来的PE要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应调整的PE就只能离开了。之前在业务稳定性保障过程中起到核心作用的PE，随着各类工具平台的逐步完善，在高度自动化之后，最终也只能面临职业和技能上的转型。
+
+这种模式，与Netflix正好相反，也就是一开始技术能力无法满足要求的时候，能靠人就先靠人，然后过程中不断完善各类自动化平台。
+
+最后，再说说我自己的团队，发展过程中的模式。
+
+我大致回顾了一下，发现从去年年初到目前，将近两年的时间里，我自己的团队也没有招聘新的应用运维人员了。并不是没有合适的人，我总结了一下主要有两个原因。
+
+第一个原因，随着自动化逐步完善，效率不断提升，单个PE能够支持的业务变得越来越多；同时，很多事情开发都可以自助完成。
+
+第二个原因，我有意识地招聘具备开发能力的人员，他们入职后一方面参与各类平台的开发，另一方面还要定期轮岗做一些运维工作。后来我发现，只要有效进行引导，同时具备运维和开发能力是不成问题的。
+
+所以，结果就是，应用运维的岗位需求已经没有这么强烈了。从趋势上看，跟阿里的发展过程非常相似。不过这个过程，我从来没有刻意地设计过，基本算是顺其自然。
+
+从上面的这几个案例来看，无论哪种情况，就运维来说，随着日常重复的人工操作被逐步自动化之后，如果还是固守原有的工作模式和思路，能做的事情、能够提供的价值，一定会越来越少。终究有一天，我们会面临和阿里PE同样的转型问题，而且这个转型是在可预见的短期内就会到来。
+
+既然预见到了趋势，那下面我们就来谈谈应该如何面对。
+
+应用运维的转型
+
+如果只允许给一条建议的话，我给出的建议就是：学会写代码。
+
+我们早期的运维岗位，基本上都不会对代码能力有很强的要求。所以对这个岗位上的同学来说，这一点就成了技能上最大的短板，也成了后续职业发展的瓶颈限制。
+
+但是，运维行业发展到现在，无论是从趋势上看，还是从我们现在所经历的实际现状来看，单纯靠人力维护的投入越来越无效。
+
+所以，无论是我们做运维转型也好，还是做其它技术转型也好，具备代码开发能力，已经成为一项必备技能。
+
+这里多说一点，我们大多数做运维的同学不具备代码开发能力，并不是自身的能力问题。很多情况下都是因为不够自信，对写代码心存畏惧，担心自己写不好，所以一开始就把自己给限制住了。如果是这样，我给的建议再多也没用，关键还是要靠自己先迈出第一步。
+
+现在我自己的团队中，有很多同事做了多年运维工作后，因为乐于尝试和挑战，很快就可以独立编程，而且因为自身有很多一线运维经历和经验，可以说即懂业务又懂开发，反而比单纯做平台和工具的运维开发更有竞争力。
+
+下面是一些具体的建议。
+
+
+代码开发上，我的建议是可以从Python、PHP或Go这些上手比较简单的语言开始。这里不是写脚本，一定要能够实现完整的业务功能或流程。一开始尝试去做一些简单的工具，实现一些简单的功能，再往后可以通过一些复杂的业务场景深入下去。一旦场景的复杂度高了，就会涉及到更高的开发技能，比如并发、缓存、消息甚至是服务化框架等等。关键是敢于迈出第一步，然后逐步转变。相信我，真的没有那么困难，我身边有太多的优秀转型案例，都是这么过来的。
+提升产品意识。这里不是要求运维同事都成为优秀的产品经理，或者具备很强的产品设计能力，而是一定要有产品意识，只要有这么一点点小转变就会带来大不同。我简单说明一下，我们很多运维同事，甚至是资深级别的，往往还是习惯于处在最末端，前面有什么事情找到我，我就处理什么事情，属于被动响应类型的。但是，如果你有产品意识，能够将你所做的事情整理汇总起来，然后做一下流程上的串联，再把流程中每个环节步骤的功能进行详细描述，同时在梳理的过程中，将一些不合理、不规范的地方进行标准化约定，也就是我们前面说的标准化过程，然后输出的内容就是平台开发所需要的需求分析和产品PRD的雏形了。如果能将所做的事情从单纯的运维操作转化到这个维度，那我们呈现的价值就完全不一样了。
+提升技术运营意识。这一点跟上面类似，简单来说，就是如何根据需求，把承载了标准化和规范体系的工具平台真正落地应用起来。同时，在落地的过程中，通过问题收集和一定的数据分析，然后再回到产品设计和需求实现流程中进行改进，形成一个良性的闭环。
+
+
+在阿里的PE转型过程中，有一部分转型去做效能工具研发，有一部分经验丰富的资深运维就转型去做了技术产品和技术运营这样的运维专家角色。对于开发人员已经可以自助完成的部分一线运维工作，运维专家还会在这个过程中对开发做一些赋能。
+
+所以，对于当前运维岗位上的同事来说，有这样一个先天优势来承担这样的职责，可以参考阿里PE转型的经验，根据自己的优势特点提前做好方向规划。
+
+云计算和AI带给我们的挑战
+
+机遇与挑战并存，上面我们更多地讲了机遇，但是与此同时我们也要看到挑战，甚至是危机。
+
+而最大的挑战和危机往往都不是来自内部，当我们还在纠结如何不被开发替代的时候，外面的技术环境已经发生了很大的变化，而这种变化带来的将是颠覆性的改变。
+
+有两个最大的外部因素，一个是云计算，一个是火热的 AI，我们分别来看。
+
+首先，云计算发展到今天，已经不是我们想象中的只能提供IaaS服务的云平台了，目前各大公有云上的PaaS产品体系也已经非常完善。我们前面讲的各类分布式中间件产品都有覆盖，而且这些产品，还都是各大公有云平台公司在自有业务上锤炼出来的非常优秀的产品。
+
+简单一句话，现在我们去做一个业务，基于这些基础服务，完全无需自研纯技术产品，只要专注业务逻辑开发即可。我了解到国内某新兴的O2O，每日超过千万笔的订单量，除业务代码外，其它基础层面的服务就完全依赖于某大型公有云的IaaS、PaaS以及周边的各类服务体系。
+
+这种情况下，非但不再需要大量的如SA、网络工程师、DBA以及应用运维这些岗位，就连技术门槛较高的分布式中间件研发岗位也会大量缩减，所以这个挑战和危机就会非常大了。
+
+这种情况下，我们应该如何面对？其实，我在前面的文章中已经给出答案，大家可以先回顾一下，然后再往下看。
+
+这里的答案就是，从价值呈现的角度来思考我们可以做什么。至于做什么我前面也提到过，比如持续交付以及稳定性保障体系。当然根据业务的不同特点，远不止这些内容。这些都是跟业务自身层面相结合的，与平台无关。与业务结合，就会有个性和独立的地方。如何根据自己的业务特点，找到跟业务相切合的价值呈现点，是我们每一个人应该去思考和探讨的。只有找到这些点，我们做的事情才会有价值和意义，我们所在的岗位才会有价值和意义。
+
+然后，再谈谈AI。这里说明一下，我们现在谈到的AI，其实大部分情况是在谈论AI的一种实现方式，就是机器学习算法。关于这一点我在InfoQ分享过一篇文章，我把链接附在文末，如果你感兴趣可以读一读。
+
+AI和Ops的结合，更多还是场景驱动的。就是我们要处理的数据量越来越多，面对的场景越来越复杂，而且会大大超出我们人力的认知范畴。比如BAT这样的公司，几十万台服务器的规模，出现一个问题，我怎么能够快速发现，快速定位，并最终快速恢复？如果是几百甚至几千台服务器，靠人还是可以搞定的，但是几十万台，靠人就不可能了。
+
+所以，这个时候，就需要借助技术的能力，而机器学习算法又正好可以满足我们的诉求。
+
+这里想特别提一点，机器学习算法的应用，是离不开场景和业务特点的，也就是说怎么用还是离不开人，离不开对业务和场景熟悉的人。从我现在了解到的情况来看，很多公司和团队，针对每一个场景都需要投入很大的精力去对某个特定曲线和算法进行调参优化，以确保它们的准确性，也还没有神乎其神地达到完全不靠人的无监督学习。这里面并不是说算法本身不具备这个能力，而是现实场景太复杂，我们不能用简单固化的算法来应对。
+
+说到这里，我想我们应该可以抓住这里面的关键点了，就是懂线上运维实际情况的人做这个事情，会更加适合。当然，这是极其理想的状态，因为机器学习算法的应用还是存在比较高的门槛，不仅仅是技术层面，还要一定的数学基础，需要对大数据产品有所了解等等，是个相对复杂的过程。
+
+所以，这里我的建议就是要多去了解，因为未来随着技术、数据和计算能力的提升，AI是一个必然的趋势。如果一点都不了解，极有可能就会被卡在门槛外面，这就不是转型的问题了。
+
+总结
+
+上面我结合一些运维发展到目前的现状以及呈现出的趋势，做了一些分析和建议。最后我们总结一下。
+
+新时代下，机遇和挑战并存，我们确实面临着岗位和技能的转型。我给出的建议是：学会写代码，培养产品意识，提升技术运营意识。
+
+当然，转型这个过程也不会完全是绝对和极端的，以后就一定是一个运维都不要，一个SA也不要，一个网络工程师也不要。但是，我们应该看到，这些岗位会更加收敛。一个是岗位设置上会收敛到各大云平台厂商这里，做专职的基础和后端的服务维护；同时随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。最重要的，这些岗位上的价值空间以及成长空间，将会变得极为有限，不管我们愿不愿意承认，这都是我们不得不接受的现实。
+
+同时，在云计算和AI时代我们面临的这些挑战和危机是可以预见到的，而未来还会存在大量的不确定和我们预见不到的东西，这种情况我下我们又应该如何应对呢？
+
+或许，唯一的办法就是不断地学习和提升自己的技能，保持对技术发展趋势的敏锐性，及时做出调整和应对，才是根本的解决之道。
+
+关于今天我们分享的主题和内容你有怎样的感想呢？你是否正在面临转型的困惑？是否已经成功转型，有什么经验？欢迎你留言与我分享讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+拓展阅读
+
+
+AI时代，我们离AIOps还有多远？
+
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/40运维需要懂产品和运营吗？.md

@@ -0,0 +1,75 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            40 运维需要懂产品和运营吗？
+                            在《云计算和AI时代，运维应该如何做好转型》这一期内容中，我提到两个转型建议：一个是技术产品，另一个就是技术运营。今天我就更加聚焦地来分享这个观点。
+
+我们运维接触更多的是软件生命周期中的运行维护阶段，我之前总结过一张图，就是在这个阶段要做的一些事情，把它们串起来就是下图：
+
+
+
+这张图的思路应该非常清晰了，而且对照一下我们日常在做的工作，基本上也离不开图中所描述的这些事情。
+
+这里我想表达的是，我们应该从这张图中敏锐地观察到，研发团队对运维团队的诉求，以及运维呈现的价值已经发生了变化，我们更加需要能够帮助团队建设出高效运维体系的角色，而不是能够被动响应更多问题的角色。
+
+运维的角色转变和价值体现
+
+打造一个运维体系，我们完全可以把它类比为一个产品业务体系。我们公司的组织架构中，针对一个产品或业务，如果要对其进行技术上的实现，自然就离不开类似运营提需求，产品分析设计、业务架构师设计建模、开发实现以及测试保障这样一环套一环的配合，每个角色都发挥着独特的价值。
+
+那么，对于一个运维体系，就相当于是面向研发团队内部的一套技术业务体系，只不过我们的需求方和客户是开发人员，而不是业务人员。
+
+我们对照一下可以发现，运维团队中技术环节的角色是不缺的，但是缺少的是业务环节的产品和运营角色。但是我们做事情，不一定非要有岗位上的明确设置才能往下做，只要有能起到这个作用的人承担这样的职责就够了。而这里，最合适做这个事情的，一定是运维，因为运维是日常线上运维的执行者，只有运维最清楚这里面的细节、问题和痛点，换其他人可能很难能够讲清楚。
+
+当然了，我们也不能强制要求运维一定要完全具备产品经理和运营经理的专业素养，这样就本末倒置了。这里我们强调的是运维要有产品和运营意识，总结起来最本质的就两点：第一，能将需求讲清楚；第二，能将产品推广落地。
+
+技术产品
+
+关于技术产品，其实主要就是回答以下几个问题：
+
+
+是不是能够把原本靠人工完成的很多工作转化成需求？
+是不是能够把日常工作中运维和开发的痛点转化成需求？
+是不是能够把当前系统存在的问题和隐患找出来，在解决的过程中，经过分析总结提炼成需求？
+
+
+这个过程中，可以尝试把自己做的事情串一下，用流程图也好，时序图也好，把整个过程梳理一下。过程中每个环节具体要做的事情可以通过文字描述的方式写出来，尽量分条罗列，清晰有条理。这里也可以参考我们前面讲过的内容，把一些标准化和生命周期管理的方法论融进来。这样可以一举两得，我们的标准化制定能力，场景需求分析能力慢慢都提升上来了。
+
+你可以按照我们刚才讲的内容动手做一下，这样整理出来的一份文档或者内容，其实就是一个产品PRD的雏形。如果你想要更进一步，有更加专业的输出，也可以参考了解一些产品设计方面的知识。
+
+当需求提炼出来之后，跟对应的运维开发一起合作，将需求真正落地实现。这样一个过程下来，运维的价值和能力体现是不是就跟之前有了很大的不同呢？
+
+技术运营
+
+通过上面技术产品的工作，可以做出一些有针对性的工具和平台来。但是，仅仅有工具和平台还远远不够，因为只有把这个平台真正落地，并产生了实际效果，才是有意义、有价值的。这个“真正落地”就是技术运营要做的事情。
+
+所以，接下来要做的就是落地。
+
+
+平台推广落地。工具做出来了只是第一步，得要有人用，这就需要去推动落地，让大家都来使用，从而真正给团队带来规模上的效率提升。同时，我们的技术产品也是各种标准和规范的载体，在这个落地过程中，也是标准落地和执行的过程，就需要运维和开发配合做出一些改造，为后续更大规模的效率提升和平台建设打下基础。
+线上运行数据分析。通过我们的平台和工具，对线上业务和应用运行时的指标进行数据分析。比如，应用上线或者每次变更上线后，线上运行的情况是怎样的，容量有没有降，RT有没有上涨，监控有没有异常，用户体验有没有下降，用户和客服的反馈如何等等。以上这些维度和指标就需要通过数据、图表和曲线的方式呈现出来，并基于这些呈现进行分析和判断，做出后续运维决策，比如是否需要扩缩容，是否需要处理问题，是否有改进的地方。在这一点上，应该要形成对整个业务和技术架构体系改进和完善的正反馈才行。想想看，业务运营是不是也非常关注业务的数据报表，也要依赖数据情况决定后续的业务运营手段。
+过程改进。平台更多的是一个执行工具，但是工具的使用是要配合大量的标准和流程一起来运作的。比如上面我们提到的，如果一次发布之后流量下降，RT升高很多，面对这样的问题我们应该有怎样的应对机制，这里就体现出管理和流程的重要性了，要解决好不同角色和团队之间的协作问题。同时，过程中需要改进和完善的内容，能够落实到平台和工具的，也要形成正反馈，来提升我们工具和平台的效率。
+
+
+这个过程可以用下图来表示：
+
+
+
+我们面临的业务场景在不断发展和变化，这就决定了技术运营过程也必然是一个持续发展和完善的过程。所以从这个角度讲，技术运营的生命力和竞争力将会是持久的。
+
+在腾讯，运维就被定义为技术运营，第一次听到这个岗位名称时，感觉还是很贴切的。另外，我在很多大会上听海外的华人工程师分享，Operation这个词都是被直译成运营，但是在国内我们大多还是把Operation翻译成运维，从字面上就把这个岗位的定位给拉低了。
+
+不过，叫什么不重要，只要我们通过今天的内容看到，具备技术产品和技术运营的能力才是最关键的，这一点最重要。
+
+总结
+
+最后，我们再总结一下，运维虽然不是业务系统的实现者和代码的开发者，但是我们参与到了产品技术标准的制定、业务系统运维体系的建设以及后期的技术运营中，这个时候运维已然成了整个技术架构的设计者之一，而且是架构稳定和演进的看护者，这时我们所发挥的作用和呈现的价值已大不相同。
+
+从技术产品和技术运营的角度再来思考一下运维，现在的运维还是之前那个运维吗？欢迎你留言与我一起讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/41冷静下来想想，员工离职这事真能防得住吗？.md

@@ -0,0 +1,114 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            41 冷静下来想想，员工离职这事真能防得住吗？
+                            本周主要和你分享几个关于个人成长的话题。前面我们讨论了在新时期运维如何做好转型，运维是不是要懂产品和运营这两个内容，都是为了我们能够成长为技术骨干，最大限度地发挥出自己岗位的价值。
+
+今天我们就往后聊一聊，当你从技术岗位转换到管理岗后，应该如何适应新的角色，做好技术管理。技术管理这个话题很大，不是一下子就能说透彻的。所以，我就把处理员工离职问题做为一个切入点，从这个角度说起。
+
+从员工离职说起
+
+年末年初，对于任何一家公司或者一个团队来说，最令人头疼的事情就是员工离职问题，特别是骨干员工的离职，对团队带来的影响和损失，以及团队氛围和信心上的影响是非常大的。
+
+其实从员工离职这件事情上，我们还是能够反推出一些在日常管理中的问题，甚至是我们作为技术管理者自身存在的问题。同时，我们还应该从这件事情上找出我们的改进措施，不断提升我们的技术管理和团队建设能力。
+
+Design For Failure的软件架构设计理念，同样也适用于技术管理工作。
+
+因为我在EGO会员组（极客邦旗下高级技术管理者社群）专门分享过类似观点，引发了一些讨论。所以今天借着这个问题，详细分享下我在这方面的一些经历和感受，同时我也会给出一些技术管理中的反模式，这些是需要我们引以为戒的。
+
+关于员工离职的两个观点
+
+我先给出对于离职的第一个观点：对于离职这个事情，本质上就是员工个人发展和团队发展不匹配之间的矛盾。
+
+稍微解读一下就是，如果员工个人发展速度很快，而团队提供的空间或机会不足，员工就会调岗甚至离职，寻求更好的利于个人发展的机会；而如果公司和团队发展很快，员工跟不上组织发展的节奏，这种情况极有可能就会被团队淘汰。
+
+反观其它的理由，主管因素、薪酬福利，或者因为世界太大想去看看等等，这些都只能算是表面上的直接因素，或者叫导火索因素。
+
+比如，我们现在经常说的，员工离职最主要的因素之一是与主管不合。如果我们仔细想想，根本上还是因为主管在目标方向上与员工个人诉求达不成一致，或者管理方式上限制了员工个人发展，所以员工选择离开，或者团队主动淘汰，本质上的原因还是离不开发展这个诉求。
+
+但是，有时候员工对于个人成长的不满意和不顺心，无法客观理性地表达，最终就都归因到主管身上；当然作为主管，有时候不考虑员工感受和自身因素，就简单粗暴地进行管理，也不是没有问题。所以看问题要全面，我相信更多的情况是因为双方性格和风格上对不上，并没有什么是非对错，所以一切看开最好。
+
+接着彼此间发展诉求的矛盾这个问题，我再给出第二个观点：对于员工离职，从管理者角度，我们应该理解为必然结果，坦然接受，而不是避而不谈。
+
+每个人在不同阶段，总会有不同的成长和发展诉求，所以总会有一部分员工在一家公司待到一定年限之后，会为了寻求更加适合自己的机会而离开，因为员工和公司之间的发展不可能始终保持匹配，所以从这个角度来讲，员工个体上的离职是一个正常现象，也是必然结果。
+
+上面这个观点来自于领英CEO里德·霍夫曼写的《联盟》这本书，这里结合我自己的感受和理解谈一下我个人的看法。
+
+如果能意识到是必然结果，那我们要做的就是 Design For Failure，不要试图去完全避免和杜绝离职，而是要有措施能够有效规避离职带来的问题和风险。也许最大的问题在于，道理我们都懂，但是能做到的不多。
+
+所以，下面就来谈谈应该如何做好技术管理。
+
+谈谈如何做好技术管理
+
+1. 帮助员工做好个人中长期发展目标规划
+
+主管应该跟员工一起确认员工任期内的中长期成长和发展目标，让员工能够在任期内发挥最大的作用和价值，同时能够尽可能地让员工在任期内达成自己期望的成长目标。对管理者来说有一件很重要的事情，就是能够找到团队发展和员工个人发展相契合的价值点。
+
+这里很重要的一点，做技术管理者，一定要从关注事情、管理事情转换到关注人的层面。要关注人的成长发展，关注成长发展中的问题和疑惑，关怀人的工作体验和心理感受，这个才是管理的核心。一定不要忽略人这个核心要素，人的事情搞不定，其它任何事情都无从谈起。
+
+我们很多管理者当前是缺失帮助员工做中长期个人成长这件事情的，更多的是做眼前工作的任务指派，甚至是指令性下达。所以现在很多员工离职，都会提看不到发展目标，看不到空间等等。这里的关键还是上面说的管理工作缺失，大多是我们没有帮员工做，而不是真的没有空间了。
+
+这个事情要放到平时做，从团队人数还不多的时候就开始。我的团队30多人，基本每个月都和团队的每一个人做一次一对一沟通。如果实在忙不过来，那就针对核心骨干和有潜力的员工。这个沟通要持续做，并持续调整。如果放到员工要离职了再做，再去承诺，就没有意义了。
+
+2. 进行梯队建设
+
+各层管理者和HRBP，要有意识做好梯队建设，确保人才能够源源不断地输入。如有有员工离职能够有人顶上来，至少是有Backup，不至于因为一两个人离职团队就垮掉了。这块就涉及到招聘和“传帮带”机制的建立。
+
+团队成员不一定都是水平很高、能力很强的人，关键是要合适，能形成合力。所以团队中既要有经验丰富和技能突出的明星员工，又要有发展诉求强烈的骨干员工，还得要有对各种事情充满激情和新鲜感的小鲜肉。每个梯队的特点和风格不一样，形成互补，发挥各自独特的价值，这样的团队才能够有生命力。
+
+3. 提升管理意识
+
+我也是从技术转技术管理，说实话栽了很多跟头，吃了很多亏，才慢慢有所转变，这个过程比较漫长。所以，对于刚做技术管理者的员工，HR团队一定要辅助做好“转身”的培训和赋能，不然就得吃“一将无能，累死千军”的亏。
+
+同时，在这个事情上，更高级主管层面也应该要有些耐心，甚至有些时候要容许一些管理上的失误，不至于一出问题就一竿子打死。因为管理这个事情很多时候是需要管理者个人从一件件事情，甚至是一个个跟头中，一点点去“悟”到的。
+
+技术管理中引以为戒的一些反模式
+
+上面讲了做技术管理应该重点做哪些事情，那下面再说说应该少做甚至不做哪些事。
+
+1. 事必躬亲，不懂授权，不敢授权
+
+最常见的情况就是所有事情都会参与、过问甚至是干涉，更甚者，因为自己做更快，就懒得指导员工，直接亲自上手做。这样下去，久而久之，就相当于剥夺了员工成长的机会，剥夺了员工独立思考的机会。
+
+我的建议是，对于非紧急的事情，还是让员工自己动手完成。你可以指导，可以给建议，但是不要代替员工执行和思考。
+
+2. 总认为自己才是最正确的
+
+懂得授权和分配工作后，往往把自己的想法和经验强加于员工，因为总觉得自己的经验才是最好的，即使思路上和方式方法上仅有一点点不同，也要跟员工争个是非对错。长久下去，员工的主观能动性就没有了，不但容易失去与员工之间的信任，还极容易造成与员工之间的矛盾。
+
+我的建议跟上条相似，可以更多地给员工授权，多从边界条件和目标结果上提问，让员工主动思考。如果员工的方案是可以达成目标的，就可以放手让员工去做，过程中关注进展和风险，多给辅导和建议。
+
+3. 仅仅关注技术层面，忽略全局
+
+因为技术管理者大多是从技术岗位上成长起来的，有时看问题难免会片面。典型的一个问题就是只关注技术层面，不看全局。比如外部的需求澄清、进度要求、服务支持等，这些都是非技术层面的，恰恰可能也是一线员工所不擅长的，所以更需要技术管理者来关注。
+
+我的建议，技术管理者一定要先关注全局，然后再看细节。对于管理者的要求，更多的是要“做成事情”，而不再是技术骨干阶段的“做事情”。
+
+总结
+
+最后，我们来总结一下。
+
+对于离职想表达的两个观点：
+
+
+员工离职反应了个人发展与团队发展之间的矛盾；
+员工离职是个必然结果，坦然接受，做出应对，而不是谈之色变，或避而不谈。
+
+
+对于技术管理，这其实是个很大的话题，今天我们提炼一个重点：
+
+
+技术管理者，一定要重点关注人，而不仅仅是事情。这一点是做技术骨干和技术管理者之间的最大差别，也是转变思路的第一步。
+
+
+在技术管理上，你还有什么疑问，欢迎留言与我沟通讨论。
+
+这里推荐一下我们隔壁的专栏《朱赟的技术管理课》，我订购后阅读了很多文章，产生了很强的共鸣，同时也收获到一些硅谷技术公司的先进管理经验，很有帮助。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/42树立个人品牌意识：从背景调查谈谈职业口碑的重要性.md

@@ -0,0 +1,103 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            42 树立个人品牌意识：从背景调查谈谈职业口碑的重要性
+                            求职者的背景调查是我去年频繁遇到的一个职场场景，经过仔细琢磨，我有了一些自己的感受和思考。同时，这也带给我一些启发，让我对自己后续的职场表现有了一些新的认知和调整。
+
+我在这里分享出来，希望能对你有所帮助。
+
+对求职者的背景调查
+
+2017年的时候，特别是年初和年中，我陆续接到了几家公司委托的第三方机构，对我所在团队的前成员，甚至是我上家公司团队的员工做非常详细的背景调查。
+
+可能是因为与我相熟，有些公司的主管有时会直接联系我，对某些求职者在我们公司的表现和业绩情况进行了解。
+
+而且这种了解不仅限于我，我团队中的部分员工因为工作年限较长，在同行业的圈子里彼此也非常熟络，所以也会有人直接联系这些员工了解更全面的信息。
+
+背景调查对于关键岗位和高级别岗位，至少在互联网公司，已经成为了必须环节。而且越关键、越高端，背调审计就越严格。
+
+不管来自哪一方面的背调，最终被咨询一方的意见，都有可能影响到求职者的面试结果。
+
+第三方背调，一般都是在候选人经过层层选拔之后，在正式Offer发放前做的最后一项审核工作。所以如果在这个环节出现问题，眼睁睁和机会擦肩而过，就十分可惜。
+
+而对于行业同行内的背调，一般会在面试前进行。所以当你参加面试时，面试官极有可能已经对你形成了初步印象和评价，面试过程就可能是这个初步印象的验证过程。
+
+所以，面对这样的情况，我也会非常谨慎。我会尽量客观地给出我的评价标准，比如技术技能、沟通协作能力、态度表现，以及是否有比较突出的业绩贡献等等。
+
+之所以提供这些信息，是为了让对方来判断候选人的自述是否符合真实情况，以便对方做出决策。
+
+但是，两种情况下，我会比较旗帜鲜明地给出我个人的建议。
+
+第一种，对于我认为特别优秀的，我会给出强烈推荐或者非常推荐的建议。
+
+第二种，对于确实存在短板或较大自身问题的，我也会客观反馈，建议对方在候选人面试时或入职后，在管理上多加注意。
+
+我之所以这样做是因为，别人来咨询我，是对我个人的信任，我既要客观不能夸大，也不能藏着掖着掩盖事实。同时，我也要给出更加真实的一手信息。当然，我在向别人求助时，也期望别人能以同样的方式来反馈我。
+
+如何树立个人口碑
+
+谈到这里，你可能会问，既然这个环节我们自己完全不可控，那我们又怎么能确保得到被咨询人正面客观的评价呢？
+
+我的答案是：背调过程不可控，但是我们自身的表现却从来都是可控的。
+
+也就是说，我们应该把注意力放到日常工作的表现上来，因为我们所有的评价依据都来自于此。
+
+我们应该常常自问：我在工作中是否能做到积极主动，具备主人翁意识，敢于承担更多更大的责任？我在工作中是否能够不断取得成果，在团队中或跟团队一起作出较大的贡献，取得较大的业绩？
+
+以我之前公司团队的一位同事为例。
+
+这位同事是我们Oracle数据库的DBA（数据库管理员），当时他入职的时候刚毕业一年多，经验一般，但是到了岗位上很快就融入了，经常会给我提出一些在数据库层面的优化改进建议。并且在我们评审通过之后，他会自己主动去落地执行。
+
+在整个过程中，他跟其他团队成员配合得很好。出结果后，还会主动跟我一起去客户那里作汇报。久而久之，我对于他的工作很放心。后来我就放手让他自己去沟通，在他的协助下，我也减轻了一定的工作压力。
+
+后来随着能力的成长，他基本承担起了DB的全部运维职责。他在岗的那两年左右，跟团队密切配合，在确保数据库没有出现过大故障的同时，还输出了很多提升性能和容量的优化案例。（要知道Oracle数据库的优化，能够带来的成本收益还是非常巨大的。如果你了解或维护过Oracle，应该会深有体会。）
+
+在与他共事的时间里，我们更多还是同事关系，但是相比其他人，我会对他抱以更多的信任。后来他转投去别的公司工作。
+
+就在去年，我突然接到一个电话，对方是一家第三方背调公司，代表国内顶级的某支付公司，对他申请DBA技术专家岗位进行背景调查。
+
+这时我脑海里涌现出的，都是他以往种种优秀的表现。所以背调问我的每一个问题，例如表现是否突出，工作态度和责任心如何等等，我除了实事求是地回答之外，还会特别用到“非常突出”“非常优秀”之类的赞扬之词。
+
+这是比较突出的一个案例。其实绝大多数情况下，我们只要能够做到尽职尽责，态度认真，把精力投入到工作上，就不用对背调过于担心。
+
+但是如果想要树立个人的好口碑，那就需要我们付出更多，要让团队和其他成员明确你独特的个人价值，就像我上面所讲的这位同事一样。
+
+要引以为戒的反例
+
+讲到这里，我也要举两个反例，这都是我在实际工作中遇到过的情况，请你引以为戒。
+
+第一个，诚信问题，这是高压线，触碰不得。比如填写个人薪酬信息时，为了想获得更高的薪酬定价，故意捏造事实，肆意夸大之前的薪酬待遇。其实这些都是可以通过背调调查清楚的，如果存在造假，用人单位会直接拒绝。
+
+我遇到的一个真实案例就是，候选人经过了终面，但当我们通知他最后一步背调完成，然后准备发放Offer时，他却反馈不准备接受offer了。
+
+我们当然感觉比较可惜，但通过推荐人了解情况后，才得知他因为虚报薪酬太多，自己感觉心虚而不敢来了。
+
+同样，在工作岗位上千万不要故意制造假数据，或者泄露工作信息谋取个人利益，这类错误触犯的后果将会更加严重。
+
+第二个，消极怠工问题，这一点我认为是职业道德问题，是令人厌恶的。比如有的人在离职前的时间里，消极怠工，交接工作时不积极配合，经常迟到或早退，中途睡大觉或者跑出去不知所踪。
+
+可能他认为反正要离职了，一切都无所谓了，也就不再重视个人行为是否妥帖，是否合乎公司规范，是否符合起码的职业道德和职业素养。
+
+而这一行为恰恰会让团队其他人给他贴上“不负责任”“不靠谱”“职业素养欠缺”的负面标签。如此，他在将来背调时，可能就会因为这么简单的几个形容词，而被否定掉了，造成个人职业生涯莫大的遗憾。
+
+当然，如果你因为意见和思路与团队或他人无法达成一致，而闹情绪，传播负能量，为团队协作制造障碍等等，这种消极表现也是不可取的。
+
+共勉
+
+在职场中，我们个人的职场信息和表现，就像我们的整个求学经历一样，会被详细地记录、跟踪和完善，这就更要求我们必须要学会树立我们的个人品牌，珍视自己的职场口碑。
+
+而职场口碑的树立，关键还是来自于我们日常工作中一点一滴的表现，甚至是通过某些很细微的工作慢慢积累起来的，这是一个渐进的过程。
+
+俗话说“千里之堤溃于蚁穴”，往往一不留神，因为一件负面的事情或行为，就会使你个人职场口碑和个人品牌瞬间坍塌。
+
+所以，请守住职场底线，让我们共勉。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/划重点：赵成的运维体系管理课精华（一）.md

@@ -0,0 +1,48 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            划重点：赵成的运维体系管理课精华（一）
+                            我们的专栏原计划共36期，在三个多月的时间里，收到了你的很多反馈，我也对应做了一些补充，所以我们的运维体系管理课算是拖堂了，一直更新了42期，至此告一段落。
+
+从今天开始，我们按照专栏的四大模块，分三次来整体梳理一下。我从每一篇文章里选出一句最想告诉你的话，制作成知识卡，帮助你回顾文章内容
+
+我们专栏的四大模块分别是：
+
+
+应用运维体系建设
+效率和稳定性最佳实践
+云计算时代的运维实践
+个人成长
+
+
+愿你已拥有不一样的运维思考！
+
+应用运维体系
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/划重点：赵成的运维体系管理课精华（三）.md

@@ -0,0 +1,48 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            划重点：赵成的运维体系管理课精华（三）
+                            今天我们来梳理专栏的另外两部分，“云计算时代的运维实践”和“个人成长”。我从每一篇文章里选出一句最想告诉你的话，制作成知识卡，帮助你回顾文章内容
+
+我们专栏的四大模块分别是：
+
+
+应用运维体系建设
+效率和稳定性最佳实践
+云计算时代的运维实践
+个人成长
+
+
+愿你已拥有不一样的运维思考！
+
+云计算时代的运维实践
+
+
+
+
+
+
+
+
+
+
+
+
+
+个人成长
+
+
+
+
+
+
+
+
+
+
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/划重点：赵成的运维体系管理课精华（二）.md

@@ -0,0 +1,64 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            划重点：赵成的运维体系管理课精华（二）
+                            今天我们来梳理第二模块“效率和稳定性最佳实践”。我从每一篇文章里选出一句最想告诉你的话，制作成知识卡，帮助你回顾文章内容
+
+我们专栏的四大模块分别是：
+
+
+应用运维体系建设
+效率和稳定性最佳实践
+云计算时代的运维实践
+个人成长
+
+
+愿你已拥有不一样的运维思考！
+
+效率和稳定性
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/新书《进化：运维技术变革与实践探索》.md

@@ -0,0 +1,33 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            新书  《进化：运维技术变革与实践探索》
+                            你好，我是赵成，久等了。
+
+经过近5个月的打磨，《进化：运维技术变革与实践探索》这本书终于和你见面了。
+
+
+
+这本书的内容主要来自我的专栏。当编辑告诉我专栏文章可以集结成书出版时，我才意识到，原来我已经不知不觉地输出了一个相对比较完整的运维体系，当时的感觉：一切都是水到渠成。
+
+在专栏的基础上，我们对书的内容做了更加深度的修订。全书共十个章节，重新梳理了章节脉络使之更加清晰，让你能够更系统地阅读这本书。
+
+书稿完成后，我邀请几位好朋友写推荐和序，他们写的内容反过来给了我很多启发。我在专栏的一篇文章里说过，我的很多看法也是和业界的很多专家多次沟通交流后形成的。在这里，我把优维科技CEO王津银老师给书写的序分享给你，我们一起听听他说的话，或许你和我一样，也会有很深的共鸣。
+
+
+随着基础架构服务化越来越成熟，应用架构的服务化正走在路上，应用作为业务需求的第一载体也越来越重要了。什么是应用？为什么需要应用？有了应用，如何构成体系化的管理能力？作者的书恰恰在这些维度上给了我们详细的答案。
+
+从纵向维度——独立以Ops的阶段来看应用，应用体系的构建也涉及很多方面。作者从标准化规范体系、组织变革、工具平台、自动化、意识等多个侧面做出了讲解，论述非常全面。从横向维度来说，应用生命周期跨越了研发、测试和运维等多个角色，这里面产生了一条重要的IT交付价值链，也就是今天DevOps里面讲的持续交付。说到持续交付，看似一个简单的工具链打通，却需要突破诸多障碍——组织上、工具上、文化上等。组织上来说，必须要打破部门墙，否则工具链肯定对接不上。工具平台能力要分解来看，涉及多个方面：项目管理、需求管理、环境管理、配置管理、部署管理、测试管理、监控管理、服务治理等，这些在作者的书中都给出了答案。这是非常难得的总结，是因为作者过去在研发、测试和运维上的综合经历，才能够给出这么一个体系化的指引。
+
+本书还给了我一个更重要的启示，并且作者也一直是这样践行的——对于每一个运维人来说，在如今IT业务瞬息万变的环境下，我们更需要深度地思考、总结和分享交流，才能触达问题的本质。
+
+希望你如我一样，能够从书中获取大量的养分，并反哺到你的工作中。让我们一起通过书中的文字来仔细体会作者的思想吧。
+
+
+最后，开卷有益，期望这本书能够带给你不一样的运维思考，我们共同进步。
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/特别放送我的2019：收获，静静等待.md

@@ -0,0 +1,127 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            特别放送 我的2019：收获，静静等待
+                            你好，我是赵成。好久不见！
+
+还有一周就是2020年的春节了，2019年就真的结束了。最近忙完各种年终总结、年会，终于有时间总结下自己的2019了。我把这个小复盘发布在公众号上，也想在这里分享给你。
+
+我2019年定目标的时候，并没定多大的目标，主要是害怕最后打脸，所以就定了要做三件事情：健身、英语和写字。看到这三个目标，你是不是会心一笑，谁还没立过这样的Flag呀！
+
+现在看，我还真是做到了，而且还超额了。
+
+不过，三件小事，虽然很小，但是因为坚持了一年，却给我带来了很大的改变，也是19年回顾下来，给我带来最大成就感的事情。
+
+健身
+
+到目前为止，健身坚持了一年半了，每周2～3次，每次1小时左右，有时候时间紧张，10～15分钟HIIT。
+
+18年9月份开始跟教练锻练，到19年3、4月份开始，体重就开始降，一开始是小肚子没了（八块腹肌还没出来），再到后来胸挺了（胸下垂得到有效缓解），屁股也翘了，肩膀有棱角了，背也比之前直了，总之身材变好了，穿衣服也好看了。
+
+好几次出去演讲，除了被问专业问题之外，竟然还会被人主动问到你是不是在健身，身材保持这么好，你是怎么做到的。每当被问到这样的问题，就非常开心，发自内心的喜悦。
+
+其实，19年3月份之前，我也练了差不多快半年，这半年变化不大，反而因为健身消耗比较大的原因，吃得比较多，体重不降反升，差不多长了5、6斤，特别是肚子，比原来还粗一圈。
+
+说实话，那个阶段，很长一段时间都觉得非常挫败，练了这么长时间没什么效果，真的都想放弃了。
+
+但是，变化就是在几乎要放弃，但是又想再继续坚持一下的纠结点上出现了。我自己都不敢相信，这个临界点出现后，20天不到，体重就降了10多斤，到目前为止轻了十五六斤，稳定在69公斤左右，夏天的时候会更轻一些。
+
+当然，健身带来的好处不止身材好，精神状态也好很多。之前不午休，下午就崩溃，现在反应也没这么大。之前出差折腾一下，就很疲惫，经常会头痛，要花大半天调整，现在没有任何反应，可以持续地保持非常好的精神状态。
+
+9月去敦煌走了次戈壁，3天90公里，在每天睡眠只有4个小时的情况下，体力精力已然充沛，毫无压力。
+
+
+
+还有，健身还要特别注意就是要控制饮食，所以健身后碳酸饮料基本不碰，特别甜的东西不碰，多吃蔬菜水果和高蛋白食物，早睡早起，生活状态也变地更加健康。
+
+有时候我跟人开玩笑说，我现在可以做到想胖就胖，想瘦就瘦，其实我现在真的可以做到，秘诀就在于自律带来的“体重”自由。
+
+这是坚持带来的第一个小成就。
+
+英语
+
+坚持了一年的英语学习，每周两次外教口语课，每天读几篇英文新闻和文章，听个5～10分钟英文新闻或演讲或访谈，坚持读了四本英语原版图书，看得比较慢，但是一点点都能看懂了，慢慢地速度也提上来了，虽然做不到一目十行，但是相对熟悉的内容范围内，一目2～3行还是可以的。
+
+
+
+其实最早触发我重新捡起英语的原因是，我想申请海外的国际会议演讲。所以19年初尝试报名了SRECon亚太区演讲，申请的Proposal在好友的指导和帮助下竟然通过了。这个会议的通过率差不多是10%，当时真的很兴奋。
+
+6月份去新加坡做了第一次英文演讲，终于走向国际舞台了，跟LinkedIn、Facebook和Google的大牛们同台了，当时我的外教老师给我发了条消息：The world is our stage（世界才是我们的舞台）。
+
+哈哈，还是忍不住开心下。
+
+
+
+不过，过程我不是很满意，因为那个时候无论在发音、节奏、流畅和精准表达上，都差很多，只能算是一次当场的英文表达，并不能算演讲。
+
+当时在会场上有很多国家和地区的工程师，口音都不一样，特别是印度口音，完全follow不上，当时被一个印度的工程师提问，直接给问懵逼了，好在有朋友在，临时给救了场。
+
+Anyway，这算是一个美好而有意思的开始。
+
+
+
+再说件特别的事情。这次过去，还见到了我20多年没见的高中班主任，当时给过我莫大的鼓励和启蒙的老师，很多过往多年的记忆也一点点被勾起。
+
+原本一个很小的期望，去做一场国际演讲，然后打开了英语学习之门，然后体会到了阅读英文原版图书和与国际友人交流的乐趣，也更加开拓了视野，见到了许久未见的故人。
+
+所以，一件事情，想做就去做，做了就可能会带来完全意想不到的惊喜。
+
+英语学习的积累，跟健身一样，靠一点一滴日积月累。有时候单词不认识，长句子理不清逻辑，听力跟不上，表达想不到合适的单词，真的是想快也快不起来。
+
+咋办呢？只能一个单词一个单词地去查词典，反复地读和背，长句子反复读，把主谓宾一个个挑出来，再去看修饰部分，再理解再读，听力听不懂就反复一遍遍听，看原文，看懂了，再听，说不出来，就换啰嗦的方式表达，不行就Chinglish表达，完了再找地道的英文场景的表达方式来修正，反正就是使劲往外憋。
+
+没办法，就是一点点磨。所以，我觉得真正的学习和能力提升是永远没有捷径的，过程一定是枯燥和乏味的。
+
+其实现在也没做到流利表达，但是相比6月份，可以自信地讲，如果我再去讲一次，一定要比6月份好过N多倍。所以，争取20年再去申请一个英文Topic，做到比6月份更优秀。
+
+写字
+
+2017～2018我写了咱们这个专栏，19年就想继续沉淀自己的一些思考和收获。我看了下，19年我写了30多篇公众号文章。后来发现有些东西想到了就想写，但并不适合放到公众号里碎碎念，所以后来又开了知识星球，一年下来，写了360+篇，每篇300～800字。
+
+所以，从量上看，我觉得ok。我翻了下公众号文章，特别是上半年写的几篇，还是下了功夫，也带来比较大的阅读量，特别是有几篇转来转去，阅读量是我公众号内部的好几倍了。
+
+公众号的文章是收集信息并整理后输出的，有一定深度，自然阅读量也会不错，所以从这个角度讲，虽然有了星球可以随时写，但是今年在写作的思考深度上其实是有点偷懒了，公众号发的文章偏少就是这个特征，这里是要反思和改进的。
+
+所以，2020年，我会继续回到极客时间，会有一个小专栏输出，可以期待下。
+
+三件小事的总结
+
+无论是健身、学英语、还是写文章，我当初并没有立什么具体的Flag，没有了Flag的压力，我反而没有了太多的压力，完全当兴趣和小挑战来做，就是坚持，尽量不中断。
+
+而且每次努力做到跟上一次一样是最低要求，如果能做到比上一次好就更棒了，何况我健身将近半年，还有点倒退，将近半年，连及格都没做到，但是好在没放弃，反而最终是变得越来越好，甚至超出我原来自己心目中的想象。
+
+后来，我也想明白一个理儿，就是无论健身还是英语，都是我对我自己的期待，我做得好与不好，只对我自己有影响，并不影响别人怎么样，当然其实别人也并不care你身材好不好，能不能张口说漂亮的英语，关人家啥事呢。
+
+我想做的只是改变我自己，我没有必要非得立个Flag给别人看。
+
+所以，在个人成长上，努力做好自己，坚持对个人有益的一些小事，努力做到比上一次好一点点，我就觉得已经受益匪浅了。
+
+今年得到年会上，罗胖第一张PPT分享就是贝聿铭的名句：“我一直沉浸在如何解决我自己的问题之中”，很有共鸣。
+
+健身给我带来了更多自信，身体好心情也不会太差，精神更充沛的情况下，也保证了我有更充足的精力做更多其它有挑战性的事情，英语可以帮我打开一个新的空间，比如看英文原版书，跟国际友人交流，去国外演讲，阅读和写字，让我可以结交和认识更多志同道合的朋友，也让更多的认识我、了解我，而且还有机会到更大的内容平台上是展示，本身就是个品牌建设过程。
+
+所以，坚持的力量在一个人身上总会以某种方式呈现出来，比如，别人会主动问，你的身材这么好，是怎么练出来的。
+
+工作
+
+还是聊聊跟云的关系，18年的时候，我们把IaaS层的网络和主机迁到了云上，当时虚拟机、容器、还有很多中间件仍然是自建自运维。19年7月份，我们就把这些也全部迁移掉了，能用云的都用云，把上云做得更加彻底，团队精力上也可以更多地放在业务建设上，我也有更多的精力去探索一些新方向，比如5G、边缘计算、视频技术等。
+
+19年仍然有一些机会接触不同行业的同行，讨论和学习IT技术，眼界也更宽了些，也发现自己的不足，就是对某些领域的描述和呈现提炼不够，与不同级别的专家沟通，其实是需要不同层次的语言和呈现方式的，这块后续在工作中要提升。
+
+最后，2020年的计划
+
+工作上全力以赴，仍然坚持健身、英语、阅读和写字这几件小事，几件小事坚持了一年，如果能够坚持2年、3年，我觉得其实也是不小的成就。
+
+嗯，仍然不立Flag，每天或每周认真坚持几件事就好了。
+
+转一个前两天看到的句子，作为对新一年的期待：
+
+人生，难以量化，收获，静静等待。
+
+最后，你的2019是怎样的？对2020又有怎样的期待？来留言区一起聊聊吧！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/结束语学习的过程，多些耐心和脚踏实地.md

@@ -0,0 +1,74 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            结束语 学习的过程，多些耐心和脚踏实地
+                            我的运维体系管理课专栏，已接近尾声，这是最后一篇，也是我们的结束语。
+
+我打算分两部分来写，一部分来对我们的专栏学习做个总结，另一部分打算写一下专栏文章写作这件事情给我带来的改变，或者说我个人的一些收获。
+
+专栏学习的总结
+
+在学校的时候，曾经有一位历史老师讲过，历史书可以很厚，厚到将每一个历史事件和细节都记录下来，要用图书馆来保存这么多的文字内容；但是历史书也可以很薄，薄到用几句话，几段文字就可以描述，用人的脑子就可以记住，因为历史的发展规律总是相似的。
+
+我想这条规律对于我们的学习也同样适用，学习也是一个从厚到薄的过程。起初我们对一个领域或行业不熟悉，这个时候要学习大量的知识，不断向别人请教。但是在这个过程中，随着我们自己的不断实践和思考，逐步总结提炼出一条条原则和经验，甚至形成自己独有的方法论，然后再通过这些原则和经验举一反三，指导我们来应对在这个领域中所遇到的各类问题。
+
+我想我们专栏中所分享的内容，就是厚的那一部分。希望这个专栏可以给你一个指引，告诉你方向在哪里，应该从何做起，这样就不必在混沌中从头摸索；至于薄的那一部分，虽然在最后几篇文章中我们有一起复习，但是，更希望你能够亲自实践和参与，形成自己的总结。
+
+这个过程，可以多一些耐心，多一些脚踏实地。
+
+对专栏的总结，我借用Bob大叔（Robert C·Martin ）最新图书《简洁架构》（Clean Architecture）中的一句话，原文如下：
+
+
+The goal of software architecture is to minimize the human resources
+required to bulid an maintain the required system.
+
+
+翻译过来就是：
+
+
+软件架构的目的，是将构建和维护所需的人力资源降到最低。
+
+
+万变不离其宗，我们整个专栏的文章和内容，其实就是围绕着这句话展开的。从厚到薄的学习过程，我想用这句话来总结，再准确不过。
+
+我在专栏写作中的收获
+
+再来谈谈专栏写作给我带来的一些改变，或者说我从中的收获，期望对你也有帮助。
+
+1.专注带来效率提升
+
+当我发现有一件非常重要，且优先级非常高的事情摆在面前时，自然而然地就能意识到哪些事情是不重要的了，也不会再为要做哪些事情，不做哪些事情而反复纠结。
+
+专栏写作对于我来说就是非常重要的事情。在一个相对较短的周期内，持续输出系统化的高质量文章，无论对我的时间，还是精力，都是极大的挑战。
+
+所以，我索性将那些相对不重要的事情暂时放下，不让它们占用我的宝贵时间，消耗太多精力。比如，我大大减少了使用手机的时间，准确来讲是减少了各类社交软件，以及各类资讯软件的使用频率，在工作时间基本不去碰这些软件，高效完成工作。写作过程中就更加坚决，除非电话打过来，否则手机也不碰。
+
+再比如，大大减少不必要的活动和会议。我有一个很简单的原则，就是超过30分钟的会议，我就拒绝，而是通过当面沟通的方式了解会议要讨论的内容，通常情况下，5~10分钟就可以得出有效结论。所以凡事事先充分准备，也成为我这段时间提升效率的关键原则。
+
+找到适合自己的节奏。我个人的习惯是早起早睡，所以我会将写作的时间安排在早上。晚上我一般会思考和策划输出内容的框架，这样第二天一早就可以专注地把内容写出来，在头脑最清醒的时候写作最高效。同时，避免周末不必要的活动和外出，大部分文章都是在周末集中输出的。
+
+总之，当我全身心投入一件事情时，原来担心的精力不足，时间不够这些情况都没有发生，反而会觉得时间更加充足，对计划的掌控更加游刃有余。
+
+2.总结回顾是最好最快的提升方式
+
+我们常常认为不断地学习新知识，一定要跟得上这个时代的所有新热点，才不至于掉队，才会不断提升。保持这种对新知识的敏感，我认为是没有问题的。但我想表达的是，学习再多的新知识，如果不能学以致用，它们都只是停留在纸面的上的内容而已。所以，单纯地学习，并不能提升技能，丰富经验。
+
+相反，对于自己正在做的事情，或者已经完成的事情，能够不断总结和反思，就能帮助我们完整地、体系化地获得提升。讲到这里，我分享下文章写作过程中的一个小细节，让我感受非常深刻，期望对你也有启发。
+
+起初我在规划内容的时候，脑子里梳理出来的东西都是大的框架，比如持续交付部分，按照原计划写4~5篇文章。但是，当我真正开始写的时候，我非常详细地回顾了我们经历过的持续交付过程，把中间的建设过程，使用到的工具集，包括如何落地执行，以及如何与外部合作这些都仔仔细细地罗列出来，突然发现我之前罗列的条条框框仍然是很粗的，所以就重新细化分解，最终用更多的篇幅完整细致地详述了整个持续交付体系。
+
+同时，这个过程中，因为要讲清楚一些细节，以及为什么要这样做，我会去翻阅和查询大量的资料，确保我自己的理解是深刻和正确的。同时，还要把以前我们为什么这样选型也重新梳理一遍，提炼出很多方案选型方面的原则。这个过程再次加深了我个人对一些原理和概念的理解，也让我自己对本来模糊或模棱两可的认知，有了更清晰的认识，对我来说也是更进一步。所谓教学相长，我觉得应该就是这个道理。
+
+整个过程下来，我的感觉就是，如果没有这样详细的总结回顾过程，很多细节和有价值的信息就随时间的漂移而遗落了，而这些信息一旦遗落，我个人如果再经历类似的过程，可能还要重走弯路，也就谈不上什么进步了。
+
+所以，在我们不断学习，接收新知识和新内容的同时，也不要忘了时常做一下总结和回顾。而总结和回顾的最好方式就是写作，希望你也可以逐步养成记录日志和博客的习惯，真的会受益匪浅。
+
+最后，感谢你的阅读和反馈。一路相伴，我们共同成长。
+
+希望你能够通过专栏的学习，更进一步！
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/00篇首语张雪峰：我参与的饿了么成长轨迹中，这些事需要反思.md

@@ -0,0 +1,60 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            00 篇首语 张雪峰：我参与的饿了么成长轨迹中，这些事需要反思
+                            你好，欢迎来到《超级访谈：对话张雪峰》这个专栏，我是专栏编辑利莹。
+
+专栏缘起
+
+两个月前我和极客时间总编辑郭蕾去上海，采访前饿了么CTO张雪峰，我问他“饿了么曾经经历收购百度外卖，后又被阿里收购，技术团队经过不断分合，以及比较复杂的融合过程，你有什么感悟吗？”他给我讲了讲在不同的角色里，要保证什么样的心态。
+
+假如你是收购方，刚开始的心态一定要有包容性，因为以胜利者的姿态去收购，被收购方总会是难受的，要理解。在收购百度外卖的时候，上海的同学就是包容性不够。那假如你是被收购方，也不用太紧张，提前设定好期望值，面对最终的结果就好。
+
+这个回答是他真实经历过后的感悟，在动荡的组织中如何调整心态，很重要。收购百度外卖面临的是两个同质业务的融合，且从技术角度，是一个技术相对弱的团队收购技术相对强的团队；而被阿里收购是补充阿里生态，面临的情况是技术强的团队收购技术相对弱的团队，这是两个类型的案例，他给我做了这样的分析。
+
+其实对于饿了么的这段历史，相信很多同学也略知一二，当然最后饿了么走向被阿里收购的终点，很多人唏嘘，昔日的独角兽企业，没有逃脱这个结局。但在饿了么的发展过程中，对外竞争与对内整合，都在体现一家企业顽强的生命力。
+
+收购与被收购的故事，相信身在其中的人会有更深刻地体悟。张雪峰作为参与其中的一个重要角色，在我们的采访中，也分享了他自己的很多故事。
+
+张雪峰和饿了么的故事
+
+张雪峰从毕业后经历过几段工作，第一段是跟随国内最早的Blogger毛向辉做教育软件，两年后跳槽到第二家公司，很高兴拿到薪资翻倍，之后进入一家外企，他最大的喜悦是获得了正式地晋升。再然后就是被大家熟知的：进入微软、出来创业、成为携程国际BU CTO再到饿了么CTO，他的职业成长也是在不断做选择的过程中。
+
+进入饿了么是张雪峰职业生涯里一段非常重要的经历，他和饿了么这个企业更是相互成就。我们往往会更关注他“CTO”这个标签，但他其实也是从一个普通程序员一步步走到CTO的岗位。
+
+说一说他的成绩吧，在最初加入饿了么的三年时间里，他将技术团队从几十人扩张到近2000人，引进工程界学术界诸多技术牛人；饿了么所能支撑的日订单量级从几十万到千万。这背后的人才吸引、技术文化土壤打造、底层架构建设过程虽然艰难，但最终都变成饿了么飞速发展的坚实后盾。在IT圈，饿了么拥抱开源，还有如异地多活、智能调度等这样的技术实践非常具有行业影响力。
+
+但他自己评价自己“算是做出一点成绩的，就是跟这个团队的融合是最成功的。”我想，这也源于他对组织融合、文化融合之难的体会。
+
+在采访过程中，他更多讲了自己做得不好的地方，一些教训、失败或者要去反思的地方，比如：
+
+收购百度外卖后，在团队融合这件事上不够果敢。为了照顾两边情绪，一直不敢做大尺度融合，虽然留住了百度外卖技术团队三分之二的人，但是在这个过程中，增加了团队内耗。
+
+在异地多活的技术决策上有过犹豫，没有一步到位。饿了么异地多活外界以为是一步到位，其实没有，在做异地多活之前还做了灾备，花了不少钱，他认为这是在技术决策上的一次偏差。
+
+不搞团建，他自认为这是有错误的。有人跟他吐槽过，不搞团建，没有让团队之间良好的关系建立起来。对他来说，更是导致后面要付出更大成本去做协调，他最后也反思应该多搞搞能够让大家互相吐露心声的活动。
+
+另外，还讲到管理1800多人这样规模的技术团队的无奈，1800多人的时候，这位CTO已经做不到让绝大多数人能够享受这个工作的过程，也很难管到一线，很多一线工程师都不认识这位CTO。张雪峰离职的那天，办理离职的IT跟他说，我还是第一次见您的面，他跟我说在那个情境下感觉是很惭愧的。
+
+对于自己的职业经历，特别是在饿了么的经历，他和极客时间做了分享。我们聊了100多个问题，除了上面的故事，我还问了他这些问题，比如：
+
+
+为什么说自己是“土八路”，把百度外卖说成是“正规军”？
+从商业角度，收购百度外卖这件事是不是失败的？
+两个团队融合，技术语言要统一吗，这事你怎么处理？
+你如何让团队保持激情，喜欢自己做的事？
+工程师除了基本的技术能力外，有哪些软技能是你比较看重的？
+对团队中一个人偏爱，会不会让其他人觉得不公平？
+技术团队的价值是什么？
+……
+
+
+开始采访前，我是非常期待这些问题的答案的，如果你和我一样，那就从接下来的访谈中找答案吧！在极客时间，让技术人发声，为技术人发声，一直是一件很酷的事情，我们希望有更多技术人能分享自己，分享他们看问题的视角。这也是我们做这个专栏的初衷。
+
+接下来每一篇内容我们都会以访谈形式展现，欢迎你多发表看法，如果你觉得内容不错，也欢迎把它分享给你的朋友。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/01收购百度外卖：“土八路”收购“正规军”.md

@@ -0,0 +1,77 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            01 收购百度外卖：“土八路”收购“正规军”
+                            极客时间：为什么把自己比喻成“土八路”，把百度外卖说成是“正规军”？
+
+张雪峰：刚收购的时候，饿了么联合创始人汪渊跟我说过一句大白话，大致意思是他们（百度外卖技术团队）就是国军的整编七十四师，我们（饿了么技术团队）就是一帮还在陕北的红军，离“土八路”都还有距离，他们估计是看不上我们的，就感觉竟然被一帮“土八路”收购，大致就是这种味道。
+
+其实有一个相似的案例，就是淘宝当年收购雅虎中国这件事儿，后来有很多骨干真的是很不爽，感觉你们一帮“乡巴佬”去收购我们。当然，站在当年两边的技术底蕴和技术能力对比看，他们（雅虎中国）有这个资格说，当时淘宝就是一帮“乡巴佬”。
+
+我们虽然有一定技术成就，做了异地多活（基础设施）、智能调度（物流匹配）、Element（GitHub全球百强），但其实工程这一块还是不够成熟的，特别是跟百度这么强大的技术底蕴相比。为什么百度能成为人才工厂？是有它的道理的，而且你看现在还在源源不断输送人才，它的体系、底蕴不是一般企业能有的。
+
+极客时间：2017年收购百度外卖的时候，他们有多少人？收购完走了多少人？
+
+张雪峰：业务的人我记不住了，技术团队大概在600左右，后来陆陆续续走了三分之一，留下400人的团队。
+
+极客时间：收购消息刚下来的时候，你们都有做哪些动作？双方团队是怎么沟通的？
+
+张雪峰：是这样，最早是我们单向地找他们，我们6月底过去做尽职调查，后面7月份已经确定收购这件事，一般到尽职调查基本都确定了，百度外卖那边应该也开始通知了。
+
+正式官宣前的全员会议在北京开，但那次我没去，Mark（张旭豪，饿了么创始人、CEO）他们包括CPO都去北京开这个会去了，就是要给团队信心，去安抚一下。
+
+再之前还有一次，我们周末开管理会的时候，三个人有老巩（百度外卖原CEO巩振兵）、陈青（原百度外卖副总裁）、耿艳坤（原百度外卖CTO）到上海这边来，大家认识一下。那天我和汪渊就跟耿艳坤表达了我们的诚意，我跟艳坤说，即使收购，我们也保持不变，团队还是归你管，你不用汇报给我。
+
+那次相当于两边团队见了一下，第二天，我们就到北京再跟他们的核心团队见面，那一次耿艳坤的核心团队（不完全是他的直线汇报，也有一些关键的角色）都来了，我们这边一些重要的产品、技术的负责人也都在，那一次，大家都有点拘束，我们也不会去说做两边的融合啊什么的，绝对不能提融合，就大家say hello，认识一下，就是这样的一个过程。
+
+极客时间：当时从商业上是计划百度外卖单独运营是吧？
+
+张雪峰：其实更多是从业务上，主要是业务上的重合度比较高，当时并不是说要把百度外卖独立一个品牌，而是希望两边的份额1+1>2，形成效应。
+
+因为那时候饿了么已经被美团反超了，我们希望能追上美团，再实现反超。其实更多还是指望百度外卖在北京的份额，上海是我们占优，北京是美团占优，但百度外卖在北京做得很不错。同时，百度当时也有一个做团购的团队，后来关掉了，叫糯米，所以当时是形成了一些联动效应的。
+
+极客时间：最后耿艳坤他还是离开了。
+
+张雪峰：我也尽力了，但确实不是我可以挽回的。
+
+我们去做尽职调查的时候，技术+产品只是耿艳坤一个人来。做尽职调查，你也知道，即使你很温和，不咄咄逼人，对方可能也会感觉是有一点不爽的味道。因为我自己也有感受，我们被阿里尽职了两次（一次是投资，二次是收购）嘛，就是打破砂锅问到底。
+
+当时也问了艳坤一些问题，我尽可能温和，但有些问题没办法，你肯定要问各种数据，以及他们做的同城多活怎么样之类的，这样的问题。我知道他们肯定是不爽的。我当时就想百度外卖干脆就让他独立搞一块。
+
+但后来他闪电离职，没办法，我必须直接接管。最近我不是做“中介”吗，给大家搭线介绍工作，我也问了当时北京那边的同学，他们跟我说开始是很不信任我的，即使撸串也撸过了，喝酒也喝过了，但是他们还是感觉不信任的，估计感觉我们都是土包子，肯定会用土匪的做法。
+
+第二个大家可能的感觉，就是因为你们艳坤才离职的，谁知道是不是你在里面使绊子。但这个我没法解释，就跟我离开阿里这个事情一样，我没法解释，即使解释了，局外人也不会相信，或者更倾向自己的推测，哪怕是善意的推测。
+
+极客时间：你怎么评价百度外卖这个技术团队？
+
+张雪峰：他们的工程师，确实比我们甚至比阿里更“工程师”。阿里很多时候还要受运营的限制。
+
+极客时间：所以从技术实力来说，饿了么需要这批人吗？我听之前在饿了么的人说你很看中百度外卖的这批人。
+
+张雪峰：是的，而且他们并没有太辜负我们的期望，就按平均线来说，我们确实是逊色于百度外卖这支团队的，就是在个人素养、团队文化这方面。
+
+当然这是排除饿了么几个特例团队的啊，比如兰建刚（ 原饿了么中间件团队负责人）带的中间件团队，还有石佳宁（原饿了么中台技术团队负责人）带出来的中台团队比我们平均线要高一些。
+
+我就说素养这个东西，因为他们本身的背景，很多都是通过校招进去的，有忠诚度，还有经过百度体系的洗礼，而且他们对技术的纯粹要比我们强。
+
+极客时间：你觉得百度外卖技术团队的平均技术素养是比饿了么要高。这个技术素养是什么可以再具体讲讲么？
+
+张雪峰：这个技术素养我认为就类似于基本功，百度的人才是体系化培养出来的。饿了么其实都是江湖上搜刮来的，收购百度外卖之前我们团队有一千多人，怎么来的？在上海哪招得到那么多互联网人才啊，在上海你挖不到人的，那时候拼多多还没起来，拼拼多起来后，我也去挖人。
+
+基本上海所有相关的企业包括eBay、大众点评，我们都撸了一圈了，没人了，至少没有合适匹配的人，另外顶尖人才不在其列啊，因为这是极少部分，到哪都很难挖动。没人你只能去招非互联网行业的人，包括外企的、民企的，非互联网的传统企业技术人员，基本功确实有点参差不齐。
+
+这还是跟培养体系有关，百度就是中国特色培养出来的有很扎实技术基础的一帮人，它是相对纯粹的工程师文化或者叫工程师驱动文化。工程师文化相比技术文化会让技术人员感觉更好一些，工程师可以决定大部分的事，包括延期这些事都能决定。
+
+如果非要说国内有一家一定规模公司的技术团队能在文化和底蕴上稍微接近一点Google，那绝对非百度莫属，华为、阿里、字节、腾讯还是要差一些。
+
+而且他们很多校招进去的，校招进去培养是最好的。举个例子，你看金庸小说，为什么郭靖这么一张白纸能够练成那么厉害的武功，黄蓉这么聪明的人反而练不好？一张白纸好搞啊。江湖上混了五年的，即使不是老油条，他也有惯性思维，就像我，我也有惯性思维，即使反复提醒自己换位思考，也不是很容易接受新的一套东西重新开始的，我会认为我总是对的。
+
+很多人都在百度待了8年10年12年没有换过公司，一是忠诚度，二是他们从一开始还是蛮注重工程师培养，不是催命三郎马上要你做交付的，当然现在可能有点不与时俱进了。所以，培养体系非常重要。
+
+我们没时间搞，因为我们整天在收购被收购、融资被融资，我们只能说靠一些 Senior（高水平）的人去平衡这种技术风格，尽可能把它们聚合在一起，但其实我们更多的还是靠一些Leader的个人能力和职业素养，而不是完全靠组织培养，因为一是人才来源成分复杂，二是没有稳定周期。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/02饿了么上海本土团队和百度外卖北京团队的冲突.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            02 饿了么上海本土团队和百度外卖北京团队的冲突
+                            极客时间：我看过当时饿了么和百度外卖发的组织架构联合的通知，一共6项任命，有4项是和技术有关的，这是你们稳定百度外卖技术团队的手段吗？
+
+张雪峰：对。因为百度外卖收购价格差不多就8亿美金，离他们原先估值差很远，相当于除以3~4了，期权一下子就贬值了，所以他们其实是需要安抚的。最主要安抚的倒不是业务团队，主要还是安抚技术团队。有些同学说，钱不是万能的，但至少是对他的尊重，这个有一定道理。
+
+回过头来讲，说直白点，当时稳定团队你至少从钱上要表现出诚意。说个小插曲，在阿里收购我们之后，有一天，新的CPO说了一句话，从来没见过像饿了么这样的公司收购一个团队，给出这么好的补偿方案。
+
+极客时间：什么补偿方案？
+
+张雪峰：我们当时一是给兑换期权，应该不是完全1:N，但更重要的是我们给了现金补偿。当然现金补偿是有限制条件的，比如说一年内不能离职，逐月发给你，相当于就锁定一年不要走，当时这个策略还是相当有效果的。
+
+在宣布收购之前，我们内部其实有激烈讨论，我们要商量Announcement上写什么，其实要解决的问题很简单，就是看给北京团队什么地盘，因为钱的尊重问题解决了，接下来和钱一样重要的就是地盘尊重问题了。从业务上讲，大家都是重叠的，也都知道业务很好说，就是先不重合，比如北京以百度外卖销售为主、上海以饿了么销售为主，还是维持现状，大家不变就好。
+
+但是技术团队，我要提前考虑起来，因为我要留住这么多的核心技术人员，其实这一点上我跟公司有些分歧，但最后CEO、CPO他们还是支持了我的建议。
+
+我提了一个比较激进的方案。这也是后来上海同学可能心里会感觉有一些失落的地方吧，我把两个很重要的团队：新零售和物流的一号位都给了北京。
+
+关于新零售，我们原来也在做，其实这个是饿了么首先做出来的，就是可以在商超买东西，不光买吃的，还能送卷筒纸，送饮用水，送药，还有送充电线，我们手机充电线一直卖的很好，所以我们叫新零售，现在饿了么和美团都有。在这块业务上，两边都差不多，都有一摊。反正我们开电话会议讨论了很长时间，后来公司也是冒一定风险同意了我这个方案，就是把新零售、物流的一号位给北京的同学。实际上，新零售不止一号位，连整个技术团队都交给了北京。
+
+后来百度的同学也觉得很惊讶，就感觉居然能够给到我们这样的一个地盘，这个可能比钱更重要，我是这么想啊，但实际不一定，没有钱的尊重，可能都走不到地盘尊重这一步。他们的惊讶在于，认为这是根本不可能的，就是当时没有这样的期望值，觉得能不血洗已经不错了，也做好走人的准备了。
+
+极客时间：那上海的新零售团队呢？
+
+张雪峰：后来我们就准备把上海的新零售取消，当然这些同学我们会去安置，当时也走了一些人，事后把整个新零售技术线，全部交给北京，上海团队就等于Close掉了。
+
+还有更重要的是，我们把物流一号位经过讨论也交给北京了。虽然两边都有物流团队，但一号位大家是非常在意的，你交给北京很多人就会解读是北京物流做得更好，但其实不完全是这样。这两项任命，就相当于把上海的地盘剥离了很大一块。
+
+上海物流团队的人数跟北京相比还是多的，因为一号位给了北京，上海那个Leader差点离职，他说凭啥？他说你这不“丧权辱国”吗？但是从这个谈判来说，你收购了就是你的人，这不是“丧权辱国”。所以我当时坚持做了这件事。
+
+极客时间：为什么要这样坚持？
+
+张雪峰：为了留住北京这个团队，我不管商业上怎么样，Mark给我两个目标，一，留住技术团队；二，业务上做融合，这个不全是我的目标，后来我们空降了一个CEO过去。所以在我能力范围内，用我当时能平衡好的方式，换句话说，即使上海团队有诸多不爽，但我能控住大盘，就这样基本留住了北京技术团队。
+
+极客时间：上海的同学有说过，觉得你太照顾百度外卖的人了，他们其实有点委屈。
+
+张雪峰：是，准备收购的时候，我去过北京，回去后跟上海同学说起，确实有点数落上海同学的味道，我说你们看看你们所在的高级写字楼，下面就是地铁，周围商业繁荣。你们再看北京的同学，在上地办公，四街五街周边，简直就是五线乡镇感觉，最多就是有几栋高楼的乡镇。
+
+我说我在那边骑自行车，尘土飞扬，你们看看百度外卖同学，天之骄子啊，人家技术那么强，在那么恶劣的环境，人家把百度外卖做得那么好。我当时还专门做了一张表格，对比这两个团队，给上海同学们这样说。
+
+但后来上海同学还是怨气很大，感觉我太照顾北京同学。因为他们跟北京同学接触之后，去过上地五街之后，就感觉没你说的有那么多土、外面环境那么恶劣啊。当时链家也在那，隔得很近嘛，就感觉楼都挺不错的。
+
+上海同学说我偏心，还有一块跟Hackathon有关。饿了么每年都会举办一次Hackathon，百度外卖加入进来后，我们要看是在北京还是上海进行决赛，当然老员工们都希望在上海，后来我坚决反对，就拍死了，说必须在北京，你们的差旅费我跟公司去搞定。差旅费并不便宜，因为大部分是上海这边的人，上海参赛的人多，所以大家很不爽。
+
+大伙说我偏心，还有一个细节：每天参赛团队都要提交代码，每天刷评分，只要百度外卖同学上来，我就会在群里鼓掌，上海同学我是一概没有的，类似于这种。在会上我也说人家才多少人，你们丢不丢人，你们是做基础设施的，人家百度外卖的同学都是做业务的，他们做中间件的参赛很少。
+
+回头看，决赛到北京，其实有点劳民伤财，但对于南北一家亲以及两边团队的后续融合，我并不后悔。这方面我们很舍得投入，我也感谢公司，这一届比赛在组织上我也是做了很多努力，有些地方我比较独断专行。
+
+极客时间：你刚说到对两个团队的对比，还做了一张表格，都比较了什么？
+
+张雪峰：我可以发给你，这张表里，百度外卖北京中心叫TPU，技术就是T（Technology），P（Produce）是生产，U就是是UED，它们是合在一起的，所以叫TPU。收购百度外卖前，我们有上海研发中心和北京研发中心，当时饿了么的北京研发中心在望京，由史海峰负责。
+
+
+
+这个表格里，可能少数也有夸张成分，就是想和饿了么同学讲包容、换位思考。
+
+极客时间：你觉得百度外卖做的还是很不错的。
+
+张雪峰：其实针对我们外卖行业，我一度也怀疑是个伪需求，真正把伪需求这个“伪”抹掉的，就是百度外卖，因为他们开始做白领市场。
+
+我们和美团一开始都没意识到这个，就做高校的生意，因为对于高校学生来说，培养习惯就一点：价格，但价格恰恰是商业模式双刃剑，尤其是伤害远超过它的收益，所以不能只靠价格血拼。在上海，高校周围也有一些商业区，我们去扫楼，那个商业区的楼是很难扫的，所以我们当时感觉白领市场肯定做不起来。
+
+我们感觉白领看不上外卖，因为那时候还没有现在这么精美的包装，你现在看很多火锅外卖都很精美的，包装就值这个价。但那时候外卖都是白盒子，还被人吐槽说你们造成环境污染。所以我们跟美团就在高校硬干，你低一块钱，我少5毛钱，就血拼，没啥奇招。当然了，全国大网下的无数区域网格精细化运营，极其考验组织能力、运营能力，不是有钱就能砸出稳定市场份额。
+
+外卖一开始做高校市场是绝对亏的，如果我们一直做高校一定死无葬身之地。百度外卖的逻辑其实蛮有道理的，我认为整个行业应该感谢百度外卖。百度外卖做白领，虽然还是亏损，但一下子找到了商业模式，因为客单价上去了。
+
+我跟你说，开餐饮是很苦的，虽然毛利是有50%甚至60%，但是房租、人员成本都是很大开销，所以商户是比较欢迎让别人去配送，就是不要让他们自己去配送，他们想人越少越好。房租和人员成本这两个去掉，之后的毛利可能只有20%甚至15%，另外，平台还有费用，比如：佣金、物流、广告、营销等等。
+
+其实饿了么本质上跟携程是一样的，就是抽佣，但携程客单价多高？虽然机票是薄的，但一般用携程订机票的有相当比例会用携程订酒店。度假就更高了，上万都可能。所以客单价真的是决定命运。你总要找到商业模式，要赚钱的，你可以现在亏，但不能看不到尽头的亏。
+
+一个商业的正循环，一定是要有持续、合理的需求，确实C端用户能接受外卖，有这个需求。我自己刚开始感觉外卖可能是伪需求，所以我这人做商业大概率一败涂地。包括Mark已经是非常有商业头脑了，但是他一开始也没有铺开做白领。因为白领客单价上去，意味着补贴也要上去。一开始肯定是要砸钱，刚开始，白领砸的钱可能更多。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/03不够果敢带来的内耗.md

@@ -0,0 +1,85 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            03 不够果敢带来的内耗
+                            极客时间：我们前面说到血洗这个词，大家为什么觉得会被血洗呢？收购案例中血洗的情况比较多是吗？
+
+张雪峰：血洗这词或许夸张了点，大家明白意思就行。收购本身就是后妈养的，很正常。很少有被收购还能占主导地位的，单个人或小团队这种情况是有的，但是如果说美团当时把百度外卖收购，美团只会用更激烈手段。它跟大众点评是互补的还好一点，但是美团收购点评的时候也闹出了很多动静，而它跟百度外卖几乎是重叠的。
+
+当时我们收购之后，其实想着这就是和美团最后一波PK了。
+
+极客时间：针对百度外卖技术团队，做了这样的决策，最后从结果上看，达到你的预期了吗？
+
+张雪峰：整体上讲，等于把上海的利益切掉三分之一给到北京，仅从一号位角度看，给了北京两块肥肉，尤其物流这块最肥的肉。其实从组织上看，物流就是上海和北京要做融合，没有裁撤任何一边物流，但上海的新零售裁撤掉了。
+
+最后百度外卖技术团队留下了三分之二，也算是稳住了。尽管我们做了这些努力，最终还是有大约三分之一的人走掉了。其实刚开始没走三分之一那么多，刚开始只是几个Leader离开，我都是一个个谈，但后面他们还是走了。
+
+他们大部分去了顺丰（跟随原百度外卖CTO），不去顺丰的话，主动离职不多。但耿艳坤还算比较仗义的，后来我跟他还有接触，他没有一股脑把人带走。你想，即使我们给了现金待遇，即使我们给出了地盘，但如果他要带走他这些嫡系，应该也不难。所以我后来感觉他还算做的ok的，没有说他一个人走了之后就把团队搞残了。
+
+否则的话，没有管理层、没有中坚力量，你如果只留下400个兵是没有意义的。一我要从上海派人，或者我再去北京招人，但北京我不太熟，如果发展到这个地步，那业务交付就比较麻烦了，要是把上海同学派过去的话就不是出差了，而是Relocate，更麻烦。
+
+但这样如果还留不住，我也没办法了。有几次开全员会，我说我没法让你们完全信任我，只能日久见人心了，到底我是司马昭之心还是日久见人心，看我后面的行动。
+
+极客时间：除了留住了这么多人，从商业上这次收购其实是不成功的。
+
+张雪峰：我们第一个目的，就是把它的份额叠加过来，后来发现效果不好。第二个要做的，就是留住人（主要指技术团队），减轻上海技术团队巨大的招聘压力，那时在上海能招到合适的人，已经非常困难了。所以对收购这件事啊，从商业上是失败的，从技术团队来说我打70分吧。这是在我当年能力范围内能做到的最好结果了。
+
+极客时间：感觉你是有遗憾的，打了70分，如果让你现在做决策的话，你会做不同的决定吗？
+
+张雪峰：回过头来，如果我现在去做这件事，我可能会在适当的岗位做些牺牲。
+
+极客时间：怎么讲？
+
+张雪峰：因为当时给我们的时间很少，业务压力巨大，和美团白热化激战，我们要快速做决定，要给什么地盘，而且这些人没怎么共事过，相当于你要做一些赌博的。后来证明，我们把物流一号位给到崔代锐，利弊各半。
+
+有一次我们在外地开会，他在房间跟我说，雪峰，我可能要走了。我说为什么？他很坦诚，因为其实他也预感到我对他有一些不满。因为代锐到上海次数太少，一是对上海的技术团队管理不够，二是参加业务少，因为业务的总部在上海嘛，这个是被团队诟病的。后来我问他为什么，他说因为家庭原因很难频繁地到上海。最后他离职还有一个原因，他说，雪峰，我个人的兴趣还在AI算法，我对管工程团队其实有点力不从心，我兴趣不大。
+
+当时那个背景下也是赶鸭子上架。相当于说我们认为他有一定潜力，当然这个潜力是有一点点因为要考虑两边团队快速融合，同时稳住北京物流团队。其实我知道对代锐来说，是有一些拔苗助长的。所以后来相当于这个对于潜力的尝试是失败的。当然代锐也稳了团队一段时间，虽然开始很艰难，也被业务产品同学反复Challenge，但后来北京的物流团队开始形成一定战斗力了。
+
+极客时间：所以说重新再来的话，你会重新安排一些人。
+
+张雪峰：事后诸葛亮吧，比如说代锐，其实我是知道让代锐担任一号位可能有一点难度，但是因为百度内部自驱还是比较强的，他们工程不需要太费劲。蒋凡（曾任百度外卖研发中心高级研究员）也在帮他一起搞。全世界第一个外卖智能调度，其实是百度外卖做出来的，就是蒋凡和崔代锐他们搞出来的，饿了么和美团是后面才搞出来。
+
+所以如果让我重来的话，可能就安排别人接了，但这样可能会对北京的物流团队有不小冲击甚至解体，因为收购后流失的骨干，相当一部分来自北京物流团队。当时为了全局稳定，我们一下子把这两个一号位给了北京团队，当然对稳定团队还是起到很好效果。
+
+我现在感觉，到底孰对孰错分不清了，也不好说，历史没有如果。或许我当时狠一点，即使这些同学走了，但是对于公司可能是好事，当然了，也可能上海一直招不到合适的人，业务交付更慢，因为当时内耗很大，上海的同学和北京的同学都互不买账，对立程度甚至超过了后来口碑团队跟饿了么技术团队这种味道，因为饿了么毕竟是被阿里投资过，不是一下子收购，而百度外卖是瞬间就被收购了，没有任何技术融合（饿了么和阿里云前期还有技术交流）。
+
+就是因为这样一下子收购，我一直不敢做大尺度融合，当时可能有点逃避心态，就是为了照顾两边的情绪。
+
+但后来我们也产生信任感，最后他们跟我交心的时候就说很感谢，其实是我为了留住他们，增加了团队内耗。
+
+极客时间：所以你会更果敢一些。
+
+张雪峰：我那个妥协可能是，如果按两个极端来说，一个是0，一个100，我那个偏的度呢可能已经逼近20了，那最好是在45-55之间游荡，按上海同学想的就应该保留90，你最多给他们10，从单量考虑也好，从其他角度考虑也好。但其实如果论单量，百度外卖全部砍掉也不可惜，就是说这个技术团队我不要了，但我们收购是为了啥呢？至于收购之后在商业上并不成功，那也是后话，没有谁能穿越历史再来一次。
+
+我没有做到我个人心目中理想的45-55之间这样的一个balance，我一直在努力，但这件事上，现在回过头去看，如果以我现在阅历，可能会做得更好一点，但终归影响不了大局，包括之后饿了么被收购这个终点。
+
+极客时间：所以正常的操作方式还是会像阿里或者美团那样。
+
+张雪峰：对。阿里其实在本地生活上反而没怎么操作，所以昆阳（王磊，曾任阿里本地生活CEO）相当于包容了我们好几年。
+
+美团收购点评这件事情绝对是做的很漂亮。那时候团购这个东西已经江河日下了，美团收购点评的时候自身业务已经往外卖倾斜了，而且点评跟美团的业务互补性还是比较强的。但是饿了么跟百度外卖真的没办法，90%-95%业务重叠，必须要有人动，除了这些技术团队。
+
+极客时间：收购百度外卖后，你会经常到北京吗？
+
+张雪峰：对，我不知道你去过上地没有。上地信息路一直过了三街，五街是彩虹大厦，再往前，六街大概是百度地图，七街道有个拐角，拐角有一个CityGo，那时候那边成了饿了么的据点，就一直在那。
+
+技术融合之后，我最多的时候一周半到两周就要去至少待两个晚上。后面该走的也都走了，团队稳定下来之后，慢慢的就不用去那么频繁。
+
+其实这里面还有一个插曲，本来我跟耿艳坤说，我们还是两条线，你还是汇报给你那边CEO，我们融合就先别谈。先把耿艳坤留住，大家留人都是先留核心团队。而且我也知道他也是江湖味很重的，兄弟感情很深，留住他就ok了，后面稳定再说。
+
+但是很麻烦的是我们的HR体系居然也割裂了，就是我们两边各有一个HRBP。这件事情其实也是蛮为难的，我相信Mark也是思索良久最后做这个决定。
+
+后来，过了好一段时间，北京那边的HRBP走了，才慢慢把北京的HRG这条线给收起来，所以当时我同时要对接两个HR。我们半年有调薪晋升，每次这个时候，我都要用Excel跟两个人去对，还得拆开来，不能互相看到，就很痛苦，每次到晋升季的时候要选评委也是个很头疼的事。所以这里面内耗也蛮多，就是不得已的这种内耗。
+
+极客时间：现在让你评价一下坚决留住百度外卖技术团队这个决策呢？
+
+张雪峰：我坚决要把百度外卖的技术团队留住，这个决策你可以认为成功，也可以认为是失败，我也不好评判，最后双方的融合还算度过了艰难时期。其实关键是留住人，系统我不是特别在意。
+
+毛泽东曾经有一句话特别有名，“存人失地，人地皆存，存地失人，人地皆亡”，当然这个人我认为是值得留的人。但这个决策你也可以说，哎呀你们这个拖了很长时间，为了迁就百度外卖，搞得市值下跌，业务也没上去，当然不至于影响最后饿了么这个风向标，因为百度业务量少，你最多就花点钱养着，我们最后也并不是因为百度外卖这几百号员工的工资导致公司被收购。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/04“戏剧性”的裁员，反思组织融合之难“难于上青天”.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            04 “戏剧性”的裁员，反思组织融合之难“难于上青天”
+                            极客时间：之前我们聊到你说去北京要宣布裁员的事，那个过程是怎么样的？
+
+张雪峰：是这样，因为后来阿里收购我们的事情也有一些风声了。在2018年1月份，我是知道收购百度外卖这件事在商业上看来是难以继续了，远远没有达到我们预期的商业效果，当时就等于硬撑着。
+
+然后春节前都要发年终奖嘛，我们管理层就在讨论这件事，就说可能要准备裁一些人，因为要省一些成本。
+
+本来是准备要去裁员的，先从百度外卖做起，当然上海团队也要出一定裁员比例。当时我跟汪渊讨论方案，我们先跟Mark开了会，后来我俩又反复核算，说得直白点就是裁员数字，其实汪渊他是让着我的，他那边出的份额多一点，虽然我不太想搞这事，但没办法，上海、北京都要出数字。
+
+上海那时候资金可能也有点紧张，上海bonus也会有点降，但百度外卖基本就腰斩，准备要去宣布了。那天我和汪渊先坐飞机过去，准备宣布，已经快到门口了，CFO在机场刚刚降落，说立即暂停，你们现在就当什么事都没有发生，听我指挥，等我到了你们现场配合我就行了。
+
+后来我估摸着（没找CFO求证过），可能跟阿里已经到最后一步了，你这时候去裁员可能会导致一系列问题，收购之前不能出现团队的动荡。所以，后来进去之后，完全180度转变，CFO上来就是说，今天我们怎么样，我们业务怎么怎么样，说了一堆。有同学就提问说，那我们年终奖怎么办？他说如果发不到位，我就xyz。
+
+CFO这么承诺，我和汪渊傻眼了，我们白跑一趟了，来做灯泡了，只能配合他说，我们绝对会重用你们，绝对怎么怎么样。因为那时候两边融合已走上正轨，开始形成合力，所以当时这么说比收购之初更有说服力。收购一个组织，业务是一方面，人也是一方面，百度外卖这个技术团队还是优质资源，也不枉我当年偏心了他们一点。
+
+极客时间：所以阿里在收购之前，百度外卖和饿了么融合其实已经就相对是稳定的了。
+
+张雪峰：对，至少没有说刚开始就一下子走了一些人。
+
+极客时间：还有一个好奇，两个团队融合，语言要求统一吗？这个事情怎么办？
+
+张雪峰：饿了么早期用的Python，这还是比较头疼的问题，招人比较头疼，那时候还算有点体量的，就是豆瓣、知乎，我们有不少豆瓣过来的人，靠他们撑起来。后来我们再找不到用Python的人了，就只能用Java，我个人并不喜欢Java，过于臃肿，写代码太难受，但没办法。
+
+关于用什么语言，也有曲折，没有被阿里收购的时候，我已经基本做了决定，Python、PHP团队转Go，但最后很遗憾，没有实现。
+
+当时收购百度外卖就面临语言不统一这个问题，百度PHP可以说是国内最强PHP团队之一，百度外卖（核心都是老百度）过来之后坚持用PHP，后来两边折中，我说把上海的Python也废了（当时Python已经有一部分转到Java），把北京的PHP也废了，我们都用Go+Java，皆大欢喜。Java不能取代，不然你招不到人。当然，我选Go也是跟团队聊了很长时间。
+
+那时候要准备搞这个东西，我们都很兴奋。但后来阿里收购我们，我知道这事儿没戏了，不可能用Go了，阿里核心还是Java。在阿里Go基本只适用于K8S，还有一些纯粹玩技术的团队。我那时候的心情非常低落。
+
+后来行癫跟我说了一段话，他说雪峰你听我一句，我不是像外界传的那样，非要用Java，大家一直说阿里很霸道，我不是的，你们用Go，用PHP都行，但你相信我，到后面你们会很难受（指各种技术融合、业务接入等）。
+
+我们其实每一年都在收购或被收购的路上。16年蚂蚁投我们，17年我们收百度外卖，18年被阿里收购，甚至美团也多次要收购我们（指15年美团、点评合并前，一度传闻美团、点评、饿了么三合一）。所以在这条路上你完全不可控的，Mark也很无奈，他也想独立发展。
+
+所以在这种情况下，我们很多事情是有遗憾的。
+
+极客时间：很少有公司能像饿了么经历这么跌宕起伏的过程，特别是对于技术团队来说，经过不断分合，还有比较复杂的融合。如果让你给正处在这个阶段的人一些建议的话，比如计划收购别人或者将被收购的情况下，大家一定要有一个怎么样的心态？
+
+张雪峰：我们是先收购别人，我先说这个层面。你作为收购方，一定要有包容性。
+
+我们收购百度外卖，上海的同学包容性不够，真正有包容性的可能也就是我和汪渊。我知道是大家做的东西重复度是比较高的，他们道理是对的，但是我认为你好不容易收购一个团队，你先观察一段时间。我其实并不是说后面过程上的事，而是你刚开始的心态要有包容性。
+
+说难听点，你以胜利者的姿态去收购，被收购方总会是难受的。而且至少从技术角度，是技术偏弱的团队去收购技术偏强的团队，那别人肯定不爽。你要说阿里收购我们，其实我们并没有什么受害者心态，因为阿里技术本来就比我们牛逼，虽然做外卖我们更擅长。我们被阿里收购，其实我们当时是有心理预期的。
+
+被收购的团队，大家也不用太紧张。或者换句话说，你自己设定好期望值就好。
+
+如果是非常同质的业务，又是棋逢对手，有这个担心是正常的，有必要的，因为他肯定是要把你Buyout，你全部走了都无所谓。但是如果是差异业务的话，即使阿里这么厉害的团队，后来事实也证明昆阳还是比较依赖我们这些老兵的。所以如果你是差异化收购，其实不用担心。
+
+百度外卖的同学，他们担心的，一是他们感觉很委屈，我们的精锐被你们“土匪”收购。第二，这么同质的业务，他们担心你们只是把我Buyout。其实并不是收购就要Buyout，消灭一个对手，我们确实是希望把百度外卖的业务再做起来，合在一起，技术上更是这样，希望这个团队来补充我们的短板。所以也分两种情况。
+
+但我是说，站在技术团队整体不如别人的角度，确实你要有包容性。如果我们当时，比如说是百度外卖收购饿了么团队，那除了像做异地多活的团队还有一些存活空间，其他大家就自求保佑吧。
+
+所以我感觉还是看业务形态，因为技术也是为业务服务。说难听点，业务如果是要签“丧权辱国”的条约，那真没办法，但如果收购是为了补充它的短板还是有价值的。我们正好经历的第一桩Case，是业务重叠度很高的。第二桩是补充阿里的。所以两个经历过了。
+
+极客时间：在饿了么这段经历，你自己怎么评价？有什么反思？
+
+张雪峰：其实我认为我最大的幸运或者说也算是做出一点成绩的，就是我跟这个团队的融合，我认为是最成功的，在饿了么这个业务上其实并不成功，在技术上也只是尽我们最大的能力做到了，不能说有多好。
+
+但是在融合方面我对比了像国内其他这样体量的公司，要么就是空降的领导被干掉，要么就是空降的领导血洗现在的一批人，再把另一批人带进来，总之就是反复折腾。
+
+在饿了么这里，我也有教训，就包括当时收购百度外卖的时候，上面我的做法偏温和，我现在想想血腥一点可能更好，但现在他们跟我私交很好，这也是收获吧。如果当时血腥一点，现在或许早就恩断义绝了。
+
+当时我沿用了原来在饿了么的策略，快速做融合，那个效果很好，因为那时我相当于是空降，但现在变成百度外卖是收购来的，他们算是被迫空降，虽然不需要取代你的位置，但是他们希望把原来团队各种文化带来（指百度文化）。
+
+而我们有很多从腾讯过来的人，还有后来阿里进来，还有本土的（指饿了么），本土也有两拨，一拨是我加入后进来的，一拨是最早创业的，这五拨人在一起非常有挑战。阿里收购之后，还有口碑这么大的团队加进来，所以文化融合真的是比较难的问题，甚至是最大挑战，远超过业务融合、技术融合。
+
+这里有很多教训，我也反思多次。收购百度外卖，从业务看是一个失败尝试，从技术组织上看也有不少遗憾。大概走了三分之一。虽然后面我们尽可能还是把不少百度外卖骨干都留了下来，至少留到他们期权兑现为止，但是当时是有很多内耗的，即使我去强行调节，但两个团队坦率说，刚开始是完全互相看不上的。
+
+后来到阿里内部也一样，我们被阿里收购，口碑的同学也看不上我们，其实现在反过来想想完全没有必要。反而我们在Leader层还好，我跟白起，白起是原来口碑CTO，我们两个之间倒没什么大问题，但是下面的团队真的是矛盾很大。即便阿里非收购团队内部的组织之间都可能存在这种情况，更何况是我们一个被收购团队，好在我们被收购还有点价值。
+
+所以现在反过来想真的没必要。我跟你又没有什么仇，但是大家要拧成一股绳真的很难很难，尤其不同的文化。
+
+阿里、华为应该算国内组织能力非常强的企业了，其他包括美团在内，技术架构、技术能力很强，但组织能力、组织文化都要差一截，包括百度也有这样问题。
+
+组织融合跟历史很像，以李世民之能力，也不能轻易搞定他老爹之前的班底。并不是说这些老班底没有价值，只是说味道上跟你、包括你的嫡系不那么融洽。所以，我感觉一个组织内部能够真正融合，真的很难。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/05职业成长：从校园到职场的蜕变.md

@@ -0,0 +1,125 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            05 职业成长：从校园到职场的蜕变
+                            极客时间：我们会很关心用户的成长，我们平台也会有一部分用户，可能刚毕业面临一些职业选择，会有焦虑，会对自己的未来发展方向有迷茫，所以我们挺想从你的故事里让大家去找找自己的答案。
+
+张雪峰：我明白你的意思，我用那句话回答你吧，就是“幸福都是相似的，不幸的各不相同”。其实我感觉我还算幸福的，我还没到毕业就工作了，最后一年是在我们教授的实验室里做项目，那时候也算接触了互联网初期阶段。
+
+但我说的不一定大家可以借鉴，因为这种其实就是硬币的两面，你去做项目固然可以长见识，但也可能你前面三年还没打好基础，把地基打扎实也很重要，这个要因人而异。如果感觉基础没打扎实，那我建议不要直接去外面的企业实习，意义不大。
+
+只是我感觉我自己还OK，所以最后一年我就去实验室做项目，接触外面的世界了。我们当时做了上海第一个电商网站，那时候电商才刚起来，当然我只是打杂的，在后面做一些东西，能接触到一些不同的技术。
+
+迷茫也很正常，绝大部分人都是那样，天赋异禀毕竟极少数。沉下心来做事情，多和高手聊、多向前辈请教。
+
+极客时间：2000年前后，做程序员对你们来说是一个很好的选择吧？大家都想干这行吗？
+
+张雪峰：是，我学的是计算机科学专业，就业还是挺不错的。当时我毕业的时候，1800块已经算可以了，还有600块补贴。
+
+所以到了毕业的时候，我有一点底气。当时我同学有的投了100多份简历，我因为在实验室有项目经历可以写上去，所以还好，我就投了5份，拿到了2个Offer。最后我去了一家初创公司，就在上海交通大学旁边，三个创始人都是交大的。
+
+那会我就觉得我们老板真的很有个人魅力，我上下班来回通勤要四个多小时，没有地铁，更没有座位，两部公交车都是长距离，一部横穿浦西市区，另一部横穿浦东住宅区，上下班高峰都非常拥挤，那时候也没有加班打车福利，但我也很开心，乐在其中。没别的，就觉得每天工作都能学到东西，都有进步。
+
+现在大家讲所谓内卷，可能985的计算机专业都不一定有好工作，找工作都讲什么介绍、内推的，我们那时候没有的，搞编程的企业就没多少。大家比较倾向去大外企、大国企或事业单位，那时候民企是很难赚钱的。另一个靠编程赚钱的路子是做共享软件，但能做到一定规模且口碑好的很少，而能靠共享软件赚大钱的，就更少了，印象最深的就是 NetAnts、Foxmail，我自己也一度产生过是否做共享软件赚大钱的念头，还好很快掐灭了冲动的火苗。
+
+第一家公司是做教育软件的，简单说就是学校校园网的信息管理，包括考勤系统、排课系统、成绩系统，还是能赚一点钱。我们老大，在这我必须提一下大名以表感谢和敬佩，他叫毛向辉（Issac Mao），非常有技术前瞻性，比如说我们是国内最早搞XML研究和布道推广的。当时还成立了一个对应的组织，依托交大和交大学生在外面做布道，我们那时候做布道可起劲，研究各种基于XML的技术和标准，后者虽然很难，但极有成就感。
+
+同时，我印象中这位老大也是国内最早的Blogger（博客），好像没有之一，够超前吧？虽然第一家公司的业务最后没做起来，但这位老大是对我这么多年职业生涯中影响最大的一位，没有之一。之后我见过无数比这位老大更成功、更有名望、更有前瞻性的技术人，但即使算上王坚博士、行癫、鲁肃这样国内数一数二的人物，也没能再引发我当年那种对技术的无比狂热、无限憧憬，不能不说是个遗憾。
+
+那时候编程语言的话，主要用Visual Basic、Visual C++，也接触了一些国际化标准，很超前，还有包括局域网这种概念，怎么样把电脑串起来，在这家公司我基本上都体验到。但这家公司后来挂掉的原因之一也是技术（idea/prototype）太超前了，从今天来看都还有点超前，定义了很多教育行业的标准（不只局限于校园网或国内教育相关领域），也做了一些 prototype（原型）。
+
+第一段工作经历，对我个人的影响，直至今天都是巨大的，也让我在之后二十多年工作中，逐步看清了国内做软件或行业标准的无比艰难，从此不再有奢望。
+
+这中间，我还经历过Leader离职，他也是创始人之一。那时候我很震惊，感觉是不是公司快倒闭了，因为有一天他突然跟我说，雪峰，我可能要离职，部门交给你了。我很懵啊，我都没管过人，但后来还算顺利，因为主要是CEO有人格魅力，对我非常信任。
+
+极客时间：在第一家公司，你是自己在自驱地成长，还是说你前面其实有一个更强的人带着你成长？
+
+张雪峰：我自己成长。我的领导人很Nice，他都是把任务甩给我的，就让我自己摸索，我在学校有C++基础。入职后直接给了我一个月，让我做一个制作课件的软件。
+
+我自己用VC做，我VC上手其实还挺快的，因为我大四实习就用VC，但是独立做一个软件还是第一次，然后我就自己摸索，反正出了很多Bug，还把公司的一些东西误删掉了。后来我就自己折腾用恢复软件，好在恢复出来，没造成大的损失。反正就让我各种折腾，公司氛围主要是老板非常包容。
+
+所以，还是回来说刚才的问题，我觉得每个人都要走自己的路。刚毕业，没钱、没经验，但是有时间，所以一定要多折腾，怕什么，你一个光脚的怎么能怕穿鞋的啊。
+
+极客时间：你在第一家公司待了多久？
+
+张雪峰：两年。后来第二家公司也是教育软件公司，做培训+考试的，这也影响了我之后对教育行业的持续关注。现在K12被双减，职业培训就上来了，但都是民间驱动的职业培训，我们那时候职业培训主要靠政府组织，相当于是政府的定点供应商。
+
+我在这家公司的主要收获，不在技术方面，而在于收入翻倍。但现在看来，虽然工资高了，但是我职业方面的成长几乎没有。
+
+生活上，我在第二家公司任职期间，当了丈夫，当了父亲，这也是比较大的变化。
+
+极客时间：要说技术底蕴，反而第一家公司会更好，对吧？
+
+张雪峰：那绝对，第一家公司甚至超过了我自己“掌勺”的饿了么，因为饿了么我有很多要迁就的地方，但第一家公司我几乎是可以“为所欲为”的。
+
+刚才说了，第二家公司除了钱，其实对于我的职业生涯没有太大提升（接触Delphi是唯一亮点）。那时候才开始思考自己的成长问题，因为第一家公司给我的成长空间太大了，之后包括微软、饿了么在内，都没带给我这么大的技术成长空间，导致我的期望值过高，第二家公司虽然薪水双倍，但兴奋不到一年也就淡了，然后就投简历去了。
+
+后来到第三家公司，让我知道了什么叫正规化作业。第三家公司算是外企，名义上是外包软件公司，实际上也是有自己核心的东西。他们是用B/S架构，后来才知道原来美国这么先进，人家B/S早就已经如火如荼了，我们国内还在C/S呢，真是落后。
+
+现在你说AI、云计算这些是不是落后美国五年，我不好说，可能国内看着好像很繁荣，其实也有水分的。但我们那时候感觉真的是美国先进，他们包括3层架构、4层架构、N层架构，我以前只是听说过，没有实践过。
+
+那时候还没有感觉外包公司那么烂，现在外包公司就不怎么样了。那时候互联网公司没人愿意去，就感觉朝不保夕，因为我们被2000年“.com”泡沫吓怕了，那会造个网站就能融资的，2000年绝大多数就挂掉了。尤其在上海，以前的毕业生大家都希望去金融企业，去世界500强。
+
+不过，第三家公司我得到了晋升，很正式的，要去答辩的那种。我感觉那次的兴奋度超过了我在第二家公司薪水翻倍那次，因为双倍薪水的快感没多久就淡了，举个不恰当例子，那些财务自由的同学们，估计过阵子就淡了，心中依然期待财务双倍自由、财务无限自由。但晋升通过我是感觉很意外的，因为当时基本没抱什么期望，就当走过场，后来晋升了之后，就让我独立带一个项目，开始跑客户了，不是做销售，主要是了解、分析需求，和客户对技术方案。
+
+我还记得我那时候的领导是一个女孩子，岁数比我稍微大一点，她英文非常好，我有一天跟她说我要走了，她说是不是去微软？如果你去微软我就不拦你了。那时，好多 .NET 程序员，最大理想就是去微软。
+
+其实我去微软也有曲折的，去微软是面第二次才进去的。第一次面试对我打击特别大。其实我并不想去做顾问或做微软的架构师，我一直想做微软的研发，就做它的核心软件。微软那个时候有个成立不久的亚洲工程院（ATC），主要是做一些工具，比如Visual Studio，我很喜欢。当时面试我准备了很长时间，但最后没过，对我打击太大了。
+
+那个时候，我一直期待邮箱里收到一封邮件说经过怎么样怎么样我们决定怎么样怎么样，但后来等了一段时间，终于等到了一封“感谢你”，之后整个人都不好了，很长一段时间没缓过劲来。
+
+你看，这就是我经历的较大挫折之一，之后还有很多，包括饿了么期间。我真心觉得我天资普通，普通人怎么可能那么顺利呢？这次失败之后，我也在复盘、调整自己，当时我还想了挺多东西的。具体就不和大家说了，我想换作任何人，那个年龄，遭遇失败，都会反思。
+
+失败没有价值，失败之后的反思和行动才有价值。
+
+极客时间：那个时候你觉得自己技术很厉害是吧？
+
+张雪峰：我感觉还行，我那时候写文章也有些读者，文章的阅读量也还可以。那会很少有左耳朵耗子这样的持续布道牛人，当时我们就自己买书研究，书都不便宜，比如说Windows核心原理、MFC编程这种东西，这些对我来说问题不是太大，也有兴趣研究。
+
+后来第二次面试，面了5轮，我拿了Offer，去了MCS（微软咨询服务部）。当时这个岗位要出差，我那时候还比较傻，我说如果出差是不是要我自己出路费住宿费餐饮费什么的，有没有出差补贴就更不敢问了，老大说这怎么可能？全部是公司出。因为以前没出过差，就闹了这么个笑话。
+
+极客时间：你在微软待了几年？
+
+张雪峰：5年半，后来就出来创业了。其实我最后几个月已经跟北京的HR说我准备离职。HR说，“雪峰，能不能帮我个忙，最近离职太多了，我有指标压力，你能不能延到明年1、2月份，或者3月份再离职，或者到时候我们再沟通一次，能不离职就更好了”。
+
+我说我现在没法干微软的活，我也不好意思拿微软的薪水，因为接下来上班时间我要去搞另外一个事情，她说没关系，你可以做你的事情，没有薪资，但公司给你交社保公积金，微软这方面做得还是非常好的，后来接触多了，发现名声好的外企这方面都差不多。也因为这件事，我知道了一个专业术语：No Pay Leave。
+
+那时候发现还有这种操作，真的很牛。我后来在饿了么也尝试这样的办法，为了留住一些员工，我会说先让他做自己喜欢的事，哪怕回老家休息都行，我给你把社保交了，让它不要断。
+
+这里，和年轻的朋友说下，社保真的很重要，千万不要等闲视之，即使决定要离职休息几个月，也尽量通过第三方平台自己续上社保。我面试的时候，对于断过社保的同学会打个问号，因为我会想，这哥们是不是目光短浅，还是说家里有几套房？
+
+极客时间：微软这份工作给你带来最大的收获是什么？
+
+张雪峰：我认为最大的收获不在技术上，而是在视野上。因为我进了一个需要去一线的团队，需要自己解决各种问题，我要跟客户去解释，你这100万花得很值，接触这些东西，让我知道这是在做一个Business（生意）。
+
+我以前是一个很纯粹的工程师，虽然我在第二家公司第三家公司也去客户现场，但那只是了解需求，还是为了代码服务，但我在微软的时候，才知道做成一个Business有多么艰辛，哪怕已经完成签约、只是完成一个合同上的Milestone（里程碑）让客户验收通过、客户最终同意公司寄出发票、公司确认收到客户打款等等，都很艰辛。
+
+刚进微软时太天真，以为只要用Windows或Office的客户，那还不是手到擒来？只要自己嘴不太笨、整体架构不太烂、适配好所有上下游接口（那时相当多精力需要花在这上面），IBM、Oracle这些公司不都得靠边站？但是最终，每次的客户现场，都给了我最大锻炼。说人话就是，分分钟教你怎么理解业务、做好乙方。
+
+微软这段经历之后，我发现永远是人适应环境，不可能别人来取悦你或适应你。我那会也算做了半个售前（另外1/4个架构师+1/4个程序员），喝酒也是商业的一部分，这个东西只要在国内就很难避免，你就要去适应这个环境。即使我在饿了么有不小的“权力”了，但我也必须经常去适应别人（当然不是喝酒），还有业务团队。所以我变得真正发自内心愿意，而不是忍受地去适应，这是对我最大的触动和改变。
+
+还有，我们经常说去大公司学技术，我觉得不只是这样。对于一个工程师而言，技术是立命之本，但商业、管理这些东西也很重要，有机会，你还是应该跳出技术，理解技术之外的东西。
+
+极客时间：你刚才说忍受着去适应到发自内心地去适应，这应该是你成长中的一次变化，至少从微软这段经历来讲。
+
+张雪峰：对，因为我以前也经常不能换位思考，比如夫妻吵架。其实我刚从阿里退下来的时候，我跟我老婆刚过两人世界，吵架反而越来越多，后来和好，我老婆跟我总结说，以前有你爸妈在带小孩，你又在外地，念你辛苦，回来你累得要死，我也不找你发火。现在闲下来了，火气越来越大。后来我也知道她只是要找一个倾诉者、倾听者，这在企业里面也类似。
+
+我老婆和我有一阵子生气，两个人不讲话，就背对背用微信聊天，有时候我看她只要打表情包了，我就知道怒气稍微下去一点（笑）。换位思考、设身处地为对方着想，真的说易行难，我现在做得还很不够，但是微软这段经历可能是我一个转折点，我知道了商业的不容易，就是知道了在我角色之外的不容易。
+
+这个词说的简单，我毕业的时候我就说我算是一个很能换位思考的人，因为我有一定的包容性，但大部分还是忍受的包容，你不爽的时候，其实就存在你要忍受了。但是微软让我感觉可以尝试着真的去站在对方的角度思考，因为真正和你因仇恨而撕的人能有多少呢？
+
+很有意思，你看，就同样一个事情，你心态一变，结果马上就能发生变化。
+
+极客时间：刚开始到饿了么整体感受如何？
+
+张雪峰：饿了么我是很有感情，我不是饿了么第一任CTO，其实饿了么第一任CTO是科班出身的，听说他有点完美主义，跟现在很多架构师也是一样，希望完美地去上线，但是Mark（张旭豪）希望快点上线，先做出一个版本来（饿了么创业时就有MVP萌芽），我听说两人意见不一致。
+
+后来是Raymond（汪渊）接任CTO，他的第一家公司并不是饿了么。他的经历很有意思（之前InfoQ还拍过一个短视频），汪渊在第一家公司干了三个月，然后他觉得没意思，自己也不能掌控一些事情，于是就离开了。这里我说个题外话，他第一家公司的老板叫黄峥，他的直线老板是阿布。所以我跟汪渊说，你到哪都是“真龙天子”。
+
+他心胸很宽广，其实创办饿了么的这批人都能容人，格局很大，否则他们也很难接受我这么一个中年大叔，我去的时候已经40岁了，他们都是85后，还有90年的，要考虑到也许我们之间可能很难融合，但这个团队最终还是选择并接受了我。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/06拆解CTO：CTO的岗位职责.md

@@ -0,0 +1,115 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            06 拆解CTO：CTO的岗位职责
+                            极客时间：我特别好奇，从你的视角来看，CTO的职责是怎么样的？
+
+张雪峰：不同阶段CTO的职责都不一样，这个要注意。经常也会有其他公司的技术同学来问我这问题，我说我只能和你分享我的经验，具体你的场景是怎么样的，得你判断。
+
+几年前，InfoQ采访我，我当时说了5个点，分别是：找到合适人才、组建合理团队、稳定交付产品、极致经营产品和激发团队。现在我想了想，还是有一些认知变化吧。
+
+CTO本身有一些共性的我先不讲了，哪怕3个人的公司也要考虑一些技术前瞻、选型、搭建团队，等等，这些都是需要的，不可能说招一个CTO，但是他不搭团队，那就不应该叫CTO了，应该叫全栈工程师。
+
+这些前提之下呢，我认为CTO的职责主要取决于业务。业务的成长，包括业务规模，也包括它不同的边界方向，还有其他一些杂七杂八的事情，CTO都要看。
+
+或者我从三个阶段来讲。
+
+第一个阶段，以我自己的经历感觉，如果公司就是线性增长的话，一个成熟的CTO，他的职责应该没有大的变化。比如说我们从100万单量增长到500万、1000万，一个成熟的CTO他的职责应该没有大的变化。
+
+什么是线性增长？我解释一下啊，有两种，一种是规模化，一种是你做的业务差不多，只是尝试性的延伸。比如抖音现在做了无数尝试，上面小业务很多，但抖音一直没变，这个我认为也不会有技术层面的大变化。商业层面他可能要去思考，比如做抖音教育和做飞书可能是不一样的，所以这还取决于你的业务。
+
+第二个阶段，就是另外一种情况，你要做的是一个全新的、创新的，甚至大家都没做过的东西，或者说是一个你自己也吃不准的业务，这个阶段我认为CTO的职责可能会有些变化。重点就不在技术选型那些东西，而是你要为3年后考虑，考虑一个新业务的发展。
+
+这两个阶段的区别是，前一个是有迹可循的，但第二个阶段就是无迹可寻的。到了第三阶段就是CTO变成CEO，因为CTO下一步就是CEO，很少有CTO去做其他角色（转型产品负责人也是个选项），创业不算啊，所以我只讲两个阶段，我没经历过第三阶段，不好讲。
+
+第二阶段我以王坚博士做阿里云为例，这件事是对他产生挑战的，因为他要说服马云，同时马云也得相信他。做阿里云对他来说就是一个全新的职责，阿里到今天为止，给本地生活给的时间还稍微长一点，给了超过3年时间，剩下可能只有对阿里云是给了超过1年时间做探索。
+
+以前我记得的，或者我知道的，基本业务1年没达标的话，要么换人，要么砍业务，砍业务可能是有时候为了面子再撑一撑，但人一定是换掉的，不管你是什么级别，到合伙人也要换掉的。所以阿里经常组织架构调整，多岗轮换什么的就是这个原因，就是换人，当然阿里有这个底气可以去试错，是试人的错，不是试业务的错。
+
+所以对于王坚博士来说这是很罕见的，这对他的考验是：一、他自己要坚信云计算一定是未来，这时候考验CTO的眼光，绝对不是什么技术选型这种。大家说CTO还有一个词叫技术战略，我认为是跟业务相关，你是要决定公司生死的，你现在是“O”，所有的“O”都是决定公司生死存亡的，否则你就是一个执行者，我认为我在这一点上，只做到了一部分，没有完全达到我所说的这个层面。
+
+我理解的技术战略就是技术跟业务相结合的，云计算表面是一个技术，其实内核是个业务，因为有商业价值。这个不是大家说的那种纯技术战略，比如选一个三层架构还是微服务，选一个放之各种设备都能用的一套代码，这样的技术战略还是比较窄。
+
+纯粹的技术商业价值有限，最多它的价值是节流，节省成本，但它不会开源，我说的商业价值一定是开源（不是“开源软件”的开源），要能给公司带来商业的收益。包括像饿了么这么烧钱的公司，我们一直也对节流不敏感，如果一家公司要对节流敏感，要么就是出了问题，要么就是它已经很稳定要做一些精细化或人员裁汰。
+
+我前面说的总结一下就是，第一阶段是大家普遍认为的CTO要做技术战略、团队组织，包括把团队热情激发出来，技术按时按质量交付、保证稳定性；第二阶段你要思考几年后，这个技术怎么快速帮业务实现商业化、突破，技术要去坚定地相信这个业务或支持这个业务做好；到了第三阶段就是CTO变成CEO。
+
+极客时间：如果从从业视角看，比如某个人要去应聘某个公司的CTO岗位，那要往他身上安几个职责，比如3个或4个职责之类，可以这样分吗？就像刚才你其实也有说过有组织的建设，有文化的建设之类。
+
+张雪峰：这个要看公司那时的瓶颈，不同阶段和不同公司找你去做CTO的瓶颈可能不一样。饿了么当时团队更需要一个Mentor，还有那时候老宕机，要你去解决问题。当然不是每个人都要解决那么多事情的，可能有的公司就是技术影响力不够，想找个人装个门面，或者要上市了找一个CTO，这是几种不同阶段。
+
+假设抛开这些不同阶段的考虑，我把职责不分优先级地列一下。第一个职责是建组织，甭管3个人还是30个人，你一定要去Build，这个Build可能是Rebuild，有可能是Merge（融合），有可能是水乳交融（更大可能是水火难容），这个是建立组织层面，这里当然包括人才的吸引，因为组织涵盖人才。
+
+我认为饿了么已经接近水乳交融，百度外卖除外啊，因为在我离开的时候和百度外卖还没有完全水乳交融，我指的是原来饿了么老的团队和我进去之后的这个团队是水乳交融的状态。
+
+第二个职责是做所谓的技术战略，说的细一点叫技术选型，比如大到云计算这样惊天动地的抉择，小到语言，你都要做决定。其实语言也不小，但我假设是从CEO的视角出发来看技术团队的各种选择的啊，比如语言其实对CEO来说是很不敏感或很难理解的，但做异地多活这件事对CEO是敏感的，因为要花大钱，要停3个月业务，所以目前我认为可以用一个方法来看技术战略的大小、价值，就是：站在CEO角度去看CTO应该要怎么做。
+
+建组织和做技术战略这两个职责可能最重要。
+
+以饿了么为例，在第一阶段，我要解决当时团队头疼的组织问题，另外就是解决稳定性问题，当然这其实只是技术层面一小块任务啦。我总结要解决跟纯技术相关的主要就几件事：安全、稳定、性能、可扩展（灵活性伸缩性等）、可管理（运维运营等）。
+
+关于可管理，说人话就是，无论代码层面还是产品层面，要让你接班人读得懂、玩得转，你这个系统是可管理的，而不是动不动就要靠某一个人、靠一个英雄去搞定，而是可以传承的。
+
+另外大家提到CTO的职责肯定要包括稳定性，因为稳定性太突出了，尤其对规模化来说，稳定性可能超过了安全性。但我个人认为安全性是超过稳定性的，在饿了么，以前没有太多安全性方面考量，我接到这个任务是因为要解决稳定性的问题，但我进去之后，其实安全方面是花了我同等的心血。这些东西是常规的、本职的工作。我和团队经常说一句话：没有安全性，你连宕机的机会都没有。
+
+另外，关于组织也涉及到一堆事情，我刚没展开。比如说要提升团队活力，或者叫激情（仅靠激励不持久），让他们能够喜欢自己的这个岗位，包括喜欢你的角色、喜欢你做的事业，这个事还看两个层面，你是喜欢这个过程，还是喜欢结果。我个人更倾向于喜欢过程，因为你只有热爱这个事情之后，才能大概率得到一个好结果。
+
+极客时间：总结下，就是一个组织，一个技术战略？
+
+张雪峰：其实就是技术的本职和组织的本职，你要做好。因为你是CTO，这三个字母拆开来看，“T”就相当于是在技术层面，不说你写代码最强，至少技术视野没问题，你要自己做过这些东西或至少探索过，这个T你一定要有。
+
+“C”就是组织层面，你是技术组织里最重要的一号位，相当于出了事你要直接担责的，你要去更多地激发人。也不是说每个技术方面或领域都非常过硬、必须最强，但至少你自己不能不懂，不能太外行，回到本职就是“C”和“T”这两块。
+
+“O”其实是CTO的第二阶段，公司的命运、公司的新业务是跟你休戚相关的，你并不只是执行。
+
+但“O”比较难，“O”基本就是公司决策层（最高管理团队），我认为所有的“O”，至少在几个因素当中，它的权重要做到不能忽略不计那种。换句话说，你的团队和结果是要在公司的财务报表里体现或影响公司重大决策的。有很多团队和结果，是根本连上财务报表或影响公司重大决策的资格都没有。
+
+极客时间：你刚刚还说到要让团队保证激情，喜欢自己做的事，那你怎么能保证大家都喜欢过程，或者结果呢？
+
+张雪峰：我刚说更倾向让大家享受过程嘛，前提是你把他安在合适岗位。不满足的时候只能去调配，组织架构调整只是最后一招，是组织临近腐化甚至癌变的被迫手段，能不组织架构调整就不调整，当然也不可能人人都满意。
+
+我以前跟团队说，第一你要尽可能喜欢你做的事，你不喜欢做这件事你来找我，真的是这么说。我还跟大家说，如果你感觉在饿了么做技术（包括尝试内部转组后）和在其他公司做技术没啥大差别，哪怕业务相似度高达90%以上的美团外卖，那你真要考虑换个公司（换公司的另一个说法，就是炒老板鱿鱼），当然了，也可能是我和你Leader做得不到位。
+
+极客时间：在CTO所有的工作中，你觉得什么事情是最耗费你的时间和精力的？
+
+张雪峰：协调。其实最耗费时间可能是开会，但是耗费精力、耗费脑力或者最让我头疼的还是协调。
+
+极客时间：什么样的协调工作？
+
+张雪峰：我说的协调可能包括大家发牢骚，有些是个人的原因，有些是团队之间的矛盾，包括还有技术跟业务团队之间的协调。当然和业务团队有矛盾我是可以顶在前面，但是有时候是业务团队去投诉跟他对口的那个技术团队，这种情况我就很难办。
+
+有一次业务团队说，雪峰，我这边缺人，你看你们中间件团队都已经很稳定了，异地多活都搞了，还要那么多人干嘛？后来其实我也有点被他们“绑架”，我就强行跟兰建刚说，我没法完全照顾你们感受，你们要出人去做业务。
+
+后来建刚被我逼着去调人，建刚也是比较强势，但是他不会不征求意见，尤其是涉及到调人。征求意见的时候大家都不愿意去做业务。后来勉勉强强有个团队去做业务了。最后证明这次试验不成功，业务部门也不满意，被征调同学更不满意，他说我这辈子绝对不再做业务了，不管离不离职。
+
+因为他们有技术洁癖嘛，但业务那边催得急，他想做得好很难的，就觉得都是些什么狗屁需求、追求代码洁癖有错吗、质量不过关宁可推迟上线等，反正就是各种不爽。
+
+极客时间：这种抱怨如果有失偏颇了你会怎么处理？
+
+张雪峰：我更倾向于相信他。
+
+极客时间：他说的这句话，如果让做业务的同学听到，别人可能会觉得很不舒服。
+
+张雪峰：站在业务的角度这样想是对的，但是我很难去强扭、强迫他接受做业务更有价值。当然业务有同等价值，做业务很有意思，只是每个人想法不同。
+
+中间件团队建立了最扎实的地基，但是他们最讨厌装修。尤其讨厌什么呢？装修也就算了，你让我做中国式装修，每家都要推翻前面的房东，这个他绝对受不了。如果让他统一样式，精装像美国那种房子他也能装，因为一行代码就可以搞定了，但让他天天搞这种又不是完全重复，但是思想又是重复的东西，他就觉得很无聊，就感觉这是对他技术的侮辱。
+
+我面对的是这种情景，所以我也不强扭，我也不能因为他做这个不成功就惩罚他，因为他毕竟也是勉勉强强来做支援，他也没有说不负责任，还是把这事情干了的，只是说这辈子再也不做业务了。
+
+除非面临的问题是公司业务技术团队全部离职，必须你中间件团队冲上去了，那没什么悬念，你不做就走人，但没到这个程度，因为组织大了还是有一定弹性。我还是尽可能尊重个人选择。
+
+极客时间：在技术跟业务中间，你其实是一个缓冲区？因为一般的业务它总是要求快，对吧？
+
+张雪峰：对，但我也不是缓冲区，我就是顶包，这可能是我自认稍微帮兄弟们担起来的点，包括出大的故障我自己扛，或者技术跟业务有矛盾的时候。
+
+当然我自己团队内部不存在顶不顶包的问题，我肯定要协调他们，不可能所有的事都我来担，也没必要，总是老大自己担责也是有问题的，你不能走到另一个极端，什么都老大担，那小弟就会感觉反正犯错没有成本，就更不注意了。
+
+饿了么早年这样是OK的，那时候大家比较单纯，而且大家责任心非常强。但是当你团队扩大规模之后，一个是平均素质下降，二是责任心也会下降，这是正常的，这是人的本性。因为地盘就这么多，1800人做这么多模块，肯定是利益分配不均的。
+
+其实程序员就关心我做的东西能不能跟同学去吹牛。今天你做了一个不成功的东西，和一个天天可以跟同学或老婆吹牛，说这功能是我开发的，这两个事情，对于人的成就感肯定不一样，我不可能让所有人都去做那种天天可以跟同学或老婆吹牛的事情，总要有人去地里面浇水的，去收割的毕竟少。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/07对程序员来说，自由价更高.md

@@ -0,0 +1,87 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            07 对程序员来说，自由价更高
+                            极客时间：饿了么的技术文化是什么？
+
+张雪峰：用一个词来总结就是自由。自由到就是同学不爽，我可以让他换岗之类。但后面我很难做到了，因为没有那么多岗位可以让你随便调，要么就是让另一个岗位挪，要么就是我造出岗位，但这其实是一个很大的风险，因人设岗是可以的，要看什么人，你也不能经常用这种招数，绝大部分情况下，你还是要守正。
+
+刚开始我可以让同学们吐槽，因为你迁就了这个同学，让他做了自己感兴趣的，有可能他到一个新团队，别人可能跟他配合不好，所以这个也需要平衡。刚开始我基本上尽可能满足同学们的诉求。
+
+对程序员来说，自由真的是价更高，你要给他一定自由度。
+
+极客时间：除了“技术自由度”，还有别的关键词吗？
+
+张雪峰：饿了么以前其实是有六个字来代表企业精神的，叫极致、激情、创新。因为我们本身推崇的就是极客文化，刚开始完全按这个来的，因为我们CEO Mark他特别Geek，他特别推崇扎克伯格，特别推崇键盘改变世界这种理念，所以我们都受他的影响。
+
+技术团队我们当时也总结过一些词，我印象最深的就是开放、自由，我认为开放、自由，这就是我给程序员最大的两个词。
+
+极客时间：前面我们聊收购百度外卖的时候有说过工程师的技术素养问题，工程师的基础能力是基本的，除此之外，大家肯定也要有一些其他的软技能，你觉得比较重要的软技能都有哪些?比如沟通能力算不算？
+
+张雪峰：沟通这个词比较泛，举个例子，比如说最简单的Presentation的能力，不管你晋升述职还是跟老板汇报，PPT是绕不过去的，虽然很多人讨厌这种方式，但你绕不过去，因为你要让别人知道你的想法，不可能上来都是Demo、代码，这不行的。一是写PPT，二是把它讲出来。
+
+大部分的工程师都是受Linus Torvalds（林纳斯·托瓦兹，Linux之父）的影响，在不想沟通或者自己不擅长沟通、表达、分享的时候，就扔出来那句话，“Talk is cheap,Show me the code”。其实，这句话有他的语境，你看Linus的表达能力是很好的。所以，我和团队说，“Talk is important”。
+
+加入阿里后，我也参加过几场晋升述职，去担任评委，人家PPT几乎没有写得烂的，水准都很高，但是讲得有差异。演讲的技巧非常重要，而且其实这项能力在外企是特别重要，因为在外企还要用不同的语言跟别人去沟通。
+
+另外，写Email也是个技能，我有时候写Email都要反复措辞的，要发给谁，抄送给谁，还有密抄给谁，这种都需要小心的，这方面我统称为Presentation。你说的人与人沟通那属于情商，Presentation Skill是你要让对方明白，同时你要看懂对方要表达的意思。
+
+但也有些人走火入魔，比如PPT一搞就搞100页，那个也不行，还是需要抽象能力。一般来说，程序员抽象能力都还可以的。
+
+我再讲个小故事，饿了么曾经有一个小伙子，那哥们特别神奇，我很看好他，他晋升述职不用PPT，一上来就说，我本来准备了一个PPT，后来想想没必要，我就跟大家讲一讲，然后就开始脱稿讲。
+
+当时上海的评委只有一票投反对，因为他确实讲得不错，不需要PPT他能讲清楚。但这次晋升答辩北京团队清一色全部投否决票，因为这是百度体系不能容忍的方式，你这是对评委的不尊重。最后结果是我求情让他过了，这个其实不太好，但因为我对他有些偏爱。我只是举个例子说做演讲这个事情。
+
+极客时间：对一个人偏爱，会不会让其他人觉得不公平呢？你怎么看这事呢？
+
+张雪峰：肯定会有不公平议论，说实话，饿了么让我偏爱的同学比较多，有我一直在孜孜不倦准备的 CTO backup（接班人），还有就是让很多同学有“苦”说不出的我最偏爱团队 CI（Core Infrastructure）。
+
+没办法，人都有自己偏好，纯上帝视角、无利益相关几乎没人能做到，更不要说持续做到，对我来说，尽量在偏好和公平之间取得一定平衡。比如：我虽然偏爱 CI 团队，但出了故障或 CI 被吐槽、投诉，我一般也是先追杀 CI（兰建刚/徐盎/刘焱等同学苦张雪峰久矣），被我挑战最严厉的一般也是 CI 团队，即使主责或 Root cause 不在 CI 团队。
+
+又比如：我虽然偏爱石佳宁（中台技术团队负责人，二代 CTO 首选）、黄晓路（全局架构组负责人）、许红涛（商户开放平台技术负责人，三代 CTO 首选）等同学，但佳宁、晓路他们也是我在部门例会或各种群里 Challenge 最多的几位同学。
+
+极客时间：你觉得技术团队的价值体现在哪里？
+
+张雪峰：我后来到阿里，行癫（阿里云总裁、前阿里巴巴集团CTO）跟我们开会说过几次，他说技术团队的价值是什么？我们脱口而出驱动业务，他说不可能，我今天明确跟你们说，不可能。
+
+在他看来，技术只有两个核心价值。第一就是对于验证成功或接近成熟的业务，你要帮它做Scale，快速做规模化，不要线性。比如从1-10用了10天，那你从10-100应该只用两天或一天。
+
+线性就是用工程师堆业务逻辑嘛，业务逻辑就是需要人的，虽然很多人说讨厌CRUD，但也没办法，业务逻辑人工智能是搞不定的。反而中间件是很容易做规模化，非线性的东西是难度高，但一本万利。中间件一开始投入很大，比如投入100多人，这些人都很贵，公司可能说凭什么要投资他们，又看不出交付了多少业务需求。但这样考虑是不对的，一旦上线，价值非常大。
+
+第二，就是技术团队要帮业务团队快速试错。这个我是在饿了么深有体会的，Mark就总是说，你要上线了，我才知道公司这个业务行不行，能不能活下来，哪有时间让你搞什么架构。饿了么2009年第一版快速上线，绝对归功于 No Architecture，汪渊（Raymond）居功至伟。我曾和他聊过这事，如果当初饿了么找我做第一版，我绝对迅速搞（拖）垮公司，最简产品、唯快不破 vs. 完美架构、技术洁癖之间很难调和。饿了么那时候最重要的是速度，你也不要管什么战略不战略的，你就给我最快速度上线、试错。
+
+饿了么创业就是靠试错试出来的，快速创新完全是基于快速试错的，现在对这个理念我是绝对的拥趸。那种瞬间虎躯一震、如有神助、不用试错就一炮打响的成功业务，用凤毛麟角来描述都算夸张了。
+
+极客时间：“技术驱动业务”这句话在技术圈太常说了，很多人也是这么认知的，你现在对这个观点的看法呢？
+
+张雪峰：就像我刚才说的，行癫的视野是非常开阔的，我很佩服他，他说你今后不要再跟我说妄图去驱动业务，只有一种情况，像Google这样靠技术驱动纯线上业务的，才有资格去说驱动业务（今后如果无人车实现商业规模化，或许也算一种）。阿里又不是纯线上的，我们还有很多销售人员要去谈合作的，技术主要还是推进业务实现。
+
+所以现在一看到技术驱动业务的文章，我确实也不怎么会去看，除非你做的就是技术产品，比如数据库之类的基础软件产品。所以他总结的这两条技术团队的核心价值还是很淳朴的。
+
+极客时间：前面聊了很多，能感觉到你很在意同学们的职业成长，希望给大家自由度，或者说希望大家都能好好思考自己的职业生涯。
+
+张雪峰：肯定，我希望大家尽可能喜欢自己做的事，在这个层面，我也有挺多反思。比如说，其实我们前端团队经历过动荡的。
+
+有一段时间，我们所有的前端都是归Sofish（原饿了么前端负责人）一个人管的，C端、B端、物流都要做，但是后来出了问题。有人就说，这些做前端的家伙，整天去搞开源（其实有失偏颇），搞最新的那些东西，搞他们自己喜欢的那些东西。但对业务来说，我们希望进度再快一点，也希望他们能和我们一起加班，哪怕你在那磨洋工呢？人就是这个心理，不患寡而患不均。
+
+因为我跟你一个团队，都是搞技术的，你说产品经理不加班还可以理解，咱们都搞技术，你不加班，是不是你工作量不饱和？Leader会去质疑你的成员，平级（Peer）也会质疑的。
+
+但Sofish他不管这些，后来我说你面儿上也得过得去，让同学们在那边加加班。其实联调几乎都是后端的锅，前端他们做的质量确实非常好。Sofish就说，我干嘛要让他们非要待到8点以后？后来他这个团队是被我摁着加班的。
+
+后来摁不住了，我就跟他说算了，你把你做物流的前端切出去，切到了物流的研发团队，就汇报给那边。我们早期其实除了C端，都是这样的，就是每一个产品的研发包括前端和后端都是在一个团队。后来是因为Sofish做得真的很棒，所以我希望他把所有前端都管起来。这个事儿可能我当时也有点认知偏差，其实这里面是有矛盾的。
+
+比如对前端来说，你汇报给业务的研发团队，这样做业务交付，效率是最高的。但是对于个人成长，对自身的技术追求来说，其实是比较糟糕的，因为你没有同道中人啊，你跟后端没法交流。
+
+如果前端大家都坐在一起，就会很有共同语言。平时还能搞一些技术分享会，那如果你去了业务团队，你位子要搬，就可能缺少这样的条件。当然这不是绝对，只是我的看法，有些团队前端跟后端在一起也非常好，他们内部也会搞一些小技术创新什么的。
+
+但有些团队他们就感觉很失落，尤其物流团队的前端切出去之后，他们业务的交付速度是快了，但同学的职业生涯可能会有遗憾。就是我认为技术的职业生涯和你做交付的效率其实是有天然的冲突的。你很难做到让他技术有很大收获，又让他交付速度很快，因为交付速度很快证明你很难有时间学习，更何况大家不坐在一起。所以在这件事上我们走了一些弯路。
+
+另外，Sofish他其实是比较纯粹的技术人，他的主要精力还是放在对前端技术的不断追求上面，比如说性能、框架、工具。因为前端有很多的东西需要做，比如他们用的框架、工具，很多是他们自己做的。反过来，他们对业务的关注可能就有点不够。
+
+有时候我感觉，“拔苗”是可以拔的，但有些“拔苗”其实非常违背同学们本意。虽然没出什么大事，但下面大家的冲突并不少、吐槽更多，后来我就做了调整。所以，组织架构调整很难的，像阿里这么成熟的组织体系还经常调组织架构呢。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/0850X增长：管理35到1800人团队的难题.md

@@ -0,0 +1,113 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            08 50X增长：管理35到1800人团队的难题
+                            极客时间：我看到网上的资料，你刚到饿了么的时候技术团队一共35人是吗？
+
+张雪峰：2014年9月还是10月是35人，就技术加UED（用户体验设计）。然后第二年春节后就70个人了，一下翻倍，这速度很快。
+
+到2015年底大概就是五六百了，具体数字现在我记不住了。
+
+极客时间：增长蛮快的。
+
+张雪峰：那时候当然也是一步步上来的，但是确实招人太快了，我自己也要去面试一些人。
+
+从我自己的感觉，组织管理这一块，我感觉还好，还能驾驭住，没有出现吃力。跟业务团队相处也还好，可能我的强项之一就是，组建一个团队，然后快速把大家的能力或能量激发出来。
+
+极客时间：到2018年被阿里收购之前你的团队有多少人？
+
+张雪峰：1800多一点。不收购的话，其实我们本来计划要做优化了。因为以前饿了么从来不提末位，都是让大家自觉走人嘛，但是后来发现，人力成本很高。
+
+但这个也要对比来看，其实人力成本也还好，饿了么人员的薪资这些加起来，占的成本（百分比）其实是不如很多企业的，大部分线上的企业，人力成本是很大的。但是你对比其他支出来看，像我们一天三四千万的补贴就出去了，所以人员成本反而还好。
+
+极客时间：你是后来觉得人员成本也是一个比较大的支出了？
+
+张雪峰：因为我自己一开始也没经验，就是为了招人，也没有职级观念，只要感觉是个人才，他开价我就答应对吧？就进来。后来我们学阿里，开始搞组织体系、人才盘点的时候，我发现真的很心酸。
+
+我以前不看他们薪资表的，虽然能看，但我从来不看，那时候全员拉齐我看到大家的薪资，老员工们那么优秀，不少都是一万出头一点，新员工进来就两三万，而且老员工能力还比大部分新员工强。
+
+我们越到后面，到一千人的时候，或者就到2015年年底五六百人的时候，人才的平均水平其实也是掉了，组织越大越会掉。但是到了2016年、2017年，我认为人才水平是下降比较严重。但没办法，因为有很多业务要做。业务方和我讲了，机器人搞不定增删改查，说到底也不是增删改查本身，而是业务逻辑嘛。这个东西你很难去靠一个抽象的方式去弄，虽然这曾经也是我的技术理想之一。
+
+因为很多业务上线一周可能就下线了，你没法抽象，你搞得抽象就容易陷入完美主义。到今天做软件，即使你有低代码也搞不定，低代码只是让不怎么懂编程的人也可以编程，但这个还是体力活，即使拽拉也是体力活。
+
+极客时间：是的。但是人员的水平下降这事，你后来反思过吗？对企业来说，这是否是一个必然趋势？以及你有想过用什么办法提高大家的水平吗？
+
+张雪峰：我尝试过，但效果一般，整体趋势还是下滑。虽说 A Player 更倾向与 A Player 共事，但有几个制约因素：一个是公司、业务的扩张和变化，包括投融资、收购、被收购，以及因此而产生的被迫技术融合与改造，最典型就是我们遍历了国内最大的“三朵云”。
+
+第二，Leader包括我自己本身的视野局限，不是不想招更好的人才，而是你看中的Better不一定就是真正Better。一种情况是这个候选人面试水平高于实战水平，还有一种常见情况是候选人确实是真正Better，但不一定适合你的团队或者看不上你的团队。这样的候选人也会导致团队平均水准下降或氛围变差，至少团队协作方面会有问题。我认为，强强组合如果不能形成合力，有些时候甚至针尖对麦芒的话，那还不如“强+一般”这种组合形成的战斗力。
+
+我个人认为，只要企业到了一定规模，平均水准下降或者说职级通货膨胀似乎难以避免。但比这更可怕的，是团队活力、热情逐步下降，所谓各种“卷”的应运而生也没什么奇怪了。
+
+我之前尝试过拆分团队的方案，类似企业拆分 SBU/BU/BG 独立运营，但后来发现核心业务即使拆分了也是强耦合，很难独立运营，更不用说技术团队独立运营了。小而美，确实是“看上去很美”的解决方案，但有个大前提，就是：能否最大限度独立或者说灵活运营？我举个例子：微软如果拆分为 Windows、Office（平台中立）、Azure（平台中立）三个独立公司或团队，还是有可能的，但对饿了么当时业务来说，非核心业务可以拆分，核心业务没有这种可能性，因为就是强耦合，牵一发动全身。
+
+极客时间：对于业务来说，资源永远是不够的。这是所有公司的常态。
+
+张雪峰：有些时候我们要故意冗余，多招人，因为这个增删改查是绕不过去的。我现在发现几乎所有企业，就是做纯C端业务系统的，大家管程序员叫“码农”，真的有道理，确实以前码农还是一个有一点小得意的说法，还有点自鸣得意的感觉，但现在码农就是“农民”，绝大部分，相当于现在就是一个不在工地堆砖的人，真的很无聊，但没办法。
+
+极客时间：3年的时间，团队从几十人一直到1800人，这些人你们怎么招进来的？
+
+张雪峰：坑蒙拐骗（笑）。我们其实要感谢校长（这里指：极客邦科技创始人Kevin）这边。我们技术文化这块一开始顾不上，2015年我们就是解决宕机问题，到2016年开始感觉要搞搞技术文化，因为要吸引人才嘛。
+
+后来我们就想试试看能不能参加你们大会（QCon、ArchSummit等），其实你们还是很帮忙，像我们这种“屌丝”也能上大会去吹牛了（笑）。你们可能是看中饿了么业务还可以。
+
+其实我们饿了么的业务团队，就销售团队，我觉得全国可以排进前五名。但是我们技术团队，就互联网这一块，就算吹牛最多也只能排进全国前二十名，不吹牛可能更靠后一些。所以我们技术团队跟业务团队完全不匹配，后来是吸引到很多人才，慢慢拉近距离。
+
+对我们当时这样的团队来说，去大会真的是帮到大忙，稍微吹一吹牛，就能吸引到一些过去招聘渠道覆盖不到的人才。当然了，顶尖人才肯定不行，还得靠自己去聊，去“画饼”。
+
+2016年，我们筹备搞异地研发中心，那时候Mark心气很高，他说硅谷要不要搞一个，你自己去Build。我跟他说，硅谷现在还不具备条件，我们在美国没什么影响力，就在北京搞了一个研发中心，先试试水。我说能把北京的搞好，已经很不错了。饿了么的名气主要在上海，虽然北京市场也还可以，但是技术毫无名气，所以后来就先从北京开始做，北京有人了就啥都好办。这个人才只要他有一技之长，就可以去宣导宣导。
+
+我们那时候有PMO团队（Project Management Office，项目管理办公室），还帮忙搞Meetup，他们谈合作能谈到免费的场地，我觉得蛮牛逼的，我们就出去搞这种Meetup，在北京也搞过好几场。
+
+后来史海峰（原饿了么北京研发中心第二任老大）进来之后，局面就不一样了。海峰很厉害，他来了之后，和PMO在北京搞的Meetup就多起来了。海峰没进来之前，我们在北京搞得比较吃力，那时候我们还没收购百度外卖。
+
+饿了么那时候是特别需要这种宣传，但好在我感觉也没有太过火，略有一点包装，至少也达到我们的初衷了，慢慢吸引到人才。
+
+那时候我们也只能吸引国内的一些人，但我们对BAT的人才吸引力还是相对差一点，像百度的人是不会考虑来饿了么的。
+
+到后来我们有了一定名气了，为啥呢？因为那个时候腾讯云、阿里云都进来了，我们被这个投资，被那个注资。对应的，饿了么也是几朵大云的 Big Show Case，虽然很折腾，但有一个好处，至少证明你这家公司有价值，别人愿意来投你，就这样海外的人也都知道饿了么。
+
+那时候海外有两拨人，一拨人就是想回国发展的，还有一波人说雪峰，你们卖不卖代码？把饿了么卖到比利时，卖到荷兰，我说代码是不卖的，今后我们可以考虑做一个SaaS云帮你们，因为欧洲的需求都很简单，他们吃的东西本来就很简单，哪有中餐这么复杂。
+
+到了2017年，我们高阶的人才开始变多，加入不少牛人，比如Jason（张浩，现货拉拉CTO）是滴滴研究院五虎将之一，以前在Microsoft、LinkedIn、Uber；Alex（王胤）从Facebook过来，算是Facebook华人中级别还可以的大牛；Kay（范晓锋），以前在Microsoft、PayPal、蚂蚁（P9）。他们原来都在硅谷或西雅图，大部分薪资比我高不少，我们当时真的是不惜一切代价挖牛人。2017年加入这批人，对我们的技术品牌影响力非常大。
+
+然后最牛的就是何田教授，他是ACM Fellow（注：在计算机领域，仅次于图灵奖），ACM就是发图灵奖的那个机构。何教授的这个ACM Fellow，据我了解，也是阿里 + 蚂蚁两大集团史上第一个。何教授来了之后，一下子又吸引一堆人。我们以前只能吸引工程界的，包括从Facebook、LinkedIn、滴滴、百度过来，但是科学界或学术界的人很难吸引到。有了这些牛人加入，我们的AI、IoT甚至小范围科研实力也上来了。
+
+极客时间：人才吸引人才嘛。
+
+张雪峰：得人才者得天下，所以你一定要找到一些人才，或者说牛人。当然我也有过一些人才选用上的不当，但整体我认为还算顺畅。至少从组织层面我认为还可以，包括后面跟口碑的磨合，虽然磨了一两年，但最终还是和平交接了。
+
+极客时间：你之前说到喜欢过程大于结果，一般会有什么样的手段或者方法，去激活一个1800人的组织，让大多数的人去享受它的过程？
+
+张雪峰：1800人的时候我已经无能为力了，不是无能为力驾驭这个数量级的组织，而是无能为力让这个数量级的组织中的大多数人满意。以我这样的阅历、经历和驾驭能力，1800人的团队，我认为很难做到让大多数人Enjoy这个过程，或者说让每个人选自己的兴趣，这不可能的，业务还做不做呢？
+
+因为五六百人的时候我就很难管到一线了，很多人都不认识，但只要我听说过名字的，或者知道他曾经做出过一点事情的，我尽可能去关注。有人说干得郁闷，那我就跟他说你到底要什么，抛开钱不到位，郁闷就几种，要么就是他还喜欢这个工作，只不过周围的环境氛围出了问题；要么就是感觉干这个活已经很无趣，主要就这两类。我就跟他们谈，你想去哪儿，我尽可能满足。你想做什么随你挑。
+
+但是我其实挽留住的少，最后还是留不住的多。所以尽可能还是防患，就跟稳定性建设一样，到了救火的时候，我救下一两个，但是还不如我去做预防，做预防我一个人不行，这个需要组织，你要让大家感觉在这做技术是不一样的。所以，从人的角度需要组织，因为到毛细血管不是我能覆盖到的了，到1800人连HR都Cover不了。
+
+那时候（这里指2017年）我们就在楼下喝茶谈心，我下午茶就是那时候喝出来的，我其实不怎么喜欢喝下午茶的，但是大家有郁闷找我，然后就聊。对于我认为还值得留的人，我很直白，就是说随你挑，我这边虽然说比不上BAT，但也是五脏俱全。
+
+有些同学他说做业务研发烦了，想去搞机器学习，那我说你去吧。我会跟他们说得很直白，很简单，你想搞机器学习，正常情况到外面连面试资格都没有，更不要说面试通过。在我这至少是平行调过去，我可以跟那边打招呼，让你有一段时间的学习期还照发工资，还不降级的，当然除了你犯了过错。说的功利一点，这也是一个吸引手段，只要他对这还有兴趣。
+
+极客时间：你下面会有几个人直接向你汇报？
+
+张雪峰：最后收购之前大概9个、10个，最多的时候大概15个，正常状态也就大概9个、10个的样子，我们组织也经常动。我刚进去的时候虽然团队人不多，但汇报不少，但后来发现还是要靠组织力量。
+
+极客时间：直线汇报多少个人，你感觉是一个比较舒服，或者合适的状态？
+
+张雪峰：不同时期心态不一样，如果以我离开时候的心态来说，我体会更深刻一点。比如像1800人这样的组织，大概100个人配一个直接汇报，平均一下大概是15~18个，15个左右可能合适。
+
+因为我们当时1800人，其实汇报的只有那么几个，导致我后来开周会的时候，会发现这个人说不清，必须把他的直接汇报里面有一部分我认为重要的人也要拉进来才行。
+
+一开始我想汇报的人少一点，几个大业务的Leader，但后来发现不行，汇报人少了你也会懒惰的。我现在感觉就是100~150人之间配一个直接汇报，这是平均的结果，有些岗位不太一样。
+
+但只要汇报的人数多，肯定是有问题的，你要么去抽象业务，要么就是抽象组织，抽象能力是很重要的。
+
+我自己现在钻研数学和历史带给我最大的收获，归根结底还是一个抽象能力，人类进步都是这样，螺旋式上升就是抽象，我讲过，你其实还是那么回事，但是抽象层次高，能适应的范围就更广。以前大家说到抽象就是架构师的责任，现在不是，现在我认为是技术人员一个基本能力。
+
+反正我感觉就是100~150人，差不多这样的规模，以我的能力和视野，差不多可能合适，或者100~200人也无所谓，没有本质区别。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/09如何用人？.md

@@ -0,0 +1,51 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            09 如何用人？
+                            极客时间：你有开除过人吗？
+
+张雪峰：有，如果说劝退都算开除的话。
+
+极客时间：最开始的时候，会觉得很难吗？
+
+张雪峰：还好，我开始主要是考虑到汪渊的感受，对老员工从来没有开除过。
+
+我进去之后半年才决定要让一位老员工离开，你也懂什么意思对吧？我问汪渊意见，因为包括其他老员工对这个人都有投诉，但这个人有汗马功劳，然后不听任何人建议。我说这个事情怎么办，很多项目尤其涉及到跨团队项目很难搞，汪渊说你别说了，明天就让他走人，他说你别顾及我感受。后来是汪渊亲自出面，去跟这个同学谈，当天下午就办手续。
+
+我当时来的时候是希望两个团队不要出现摩擦，因为饿了么经不起大的组织折腾，当时现状就是：极速扩张、竞争激烈、频繁宕机、组织薄弱、融资不断等，我加入饿了么前那个夏天，老饿了么都经历过那段不堪回首的岁月，订单还没到日均百万，基本两天一宕机，我怎么敢随意折腾组织呢？你还得依赖老员工熟悉业务逻辑。
+
+我自己当时在这件事上有点吃不准，虽然汪渊绝对信任我，印象中从我加入到离开，我提出的稍微大一点的建议，他几乎从没拒绝过，但我还是担心会触动这些老同学神经。即使过了一段时间，我还担心老员工会有反弹，但后来事实证明还好，大家比较接受我。
+
+汪渊对我是完全信任，给我的权限非常大，无条件支持我，比如说后来搞定级，他说老员工你要降级就降级（实际并没出现这种Case），不要考虑我。
+
+极客时间：我看过一篇文章，应该大概是2015年、2016年的时候，张旭豪好像更赞成从内部去培养一些管理者。
+
+张雪峰：对，我们就那时候做的，后来发现有些培养不出来。比如人工智能我们就培养不出来，因为我自己不是这个专业的，我只是有兴趣，还是要专业人做专业事。还有就是大数据方向是有一个人，但人才还是不够。
+
+极客时间：所以那个时候挖人就是能快速解决问题的办法。
+
+张雪峰：对，当然也有一些推荐，也要聊。但是越是高阶的聊得越少，因为这种人你只能赌了，你不可能通过面试面出来的。先不说人家是不是有面试技巧，人家那个专业，就是你不擅长的领域，这时候真有点赌。
+
+极客时间：随着饿了么越来越大，你会觉得挖人越来越简单吗？
+
+张雪峰：不简单，甚至我感觉可能难度更大一点。因为公司越来越大，你要招的人层次就高了，我认为这个东西还是线性的，甚至更难。因为你大了之后，美团外卖也在大，人家更能吸引人。
+
+当年你可以不计代价的开Offer，到1800人的时候你就不能轻易打破薪酬体系了，老是破例也不行。而且到了1800人，比如某个岗位最开始没人，你招一个过来，后面你再招一个高阶过来，他们之间怎么汇报？很多高阶的人，或者说牛人在一起，尿不到一块，即使尿在一块，也很难做出好成绩。
+
+极客时间：这种情况就是1+1没法大于2。
+
+张雪峰：对，有时候反而就是一个很强的搭一个中等的，或者搭一堆普通的，反而能做得好。这个试错我都试过，强强组合，发现强强不行，强强都有个性，都想自由或者说自主，越强越这样。
+
+极客时间：如果有人要离职，你会劝别人留下吗？怎么劝？
+
+张雪峰：会劝，但是往往也留不住。有一度大家都去拼多多找工作，拼多多离我们很近，都不用装模作样请假去的，直接中午出去就可以面试了，我们内部还成立一个小组叫“打拼组”，打拼多多的挖人组（笑），但其实这种情况，对要跳槽的人来说，在这已经没有动力了，即使我不鼓励他跳槽，他自己也会想去跳。
+
+我跟他们说你在相似度这么高的业务中，如果没有发现Difference，那就再考虑考虑。我特别在意Difference，当然你根基要打牢，这叫守正出奇。“正”也就是基本功还是要有的，但要保证持续的热情还是要有一些催化剂，也就是Difference，催化剂是你一定要去思考的问题，这是我一直给他们说的话。
+
+极端一点讲，如果你在一家公司做技术，跟同质的公司没有任何区别，可能这个角色不适合你。要么是你出了问题，要么公司没法Offer你，总有一个。当然，公司毕竟是商业组织，也不会给你那么尽善尽美，所以你还得信任公司。你要去努力找到让自己兴奋的点。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/10管理的不足：不团建，管理不到毛细血管.md

@@ -0,0 +1,115 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            10 管理的不足：不团建，管理不到毛细血管
+                            极客时间：你在饿了么典型的一天大概是什么样的？工作的节奏是怎么样的？
+
+张雪峰：我还是只讲被收购前。不算周一管理例会、周五Program（技术改造）例会这种特殊日子，常规的就是到公司，首先看业务的报表，看看业务的数据。
+
+研发效能坦率说我是不看的，因为这个东西不是靠几张报表能看出来的，以前有所谓人均代码量、人均提交次数等，后来发现这很无聊，又搞什么交付时间，这也是被拼多多和抖音逼的，所以我个人不太喜欢总盯着研发效率搞KPI。其实讲研发效率就是看你自己的承诺，你自己对自己能力有一个估算，只要工作过几年，估算一个任务几天能做完，大致都能算出来的。
+
+然后第二步就是看邮件，判断要回的邮件，我Email还是蛮多的，当然有一些是杂音，但杂音我已经自动过滤掉了，有一些发布计划我是要看的。
+
+还有一点我不知道算做得好还是不好，我们其实并不要求日报，但是PMO很负责任，他们会给我发各种项目（业务交付、技术改造等）日报，会提出各种风险，他们不是暗的，不是东厂，他们就是明的锦衣卫，就是来督促大家的。比如昨天发布有什么问题让我看一下，项目的各种出错情况，有些是大项目、大节点，有些是常规的，我就看看邮件里面这一部分。
+
+我的Peer（平级）和我的上级（CEO），他们找我都是直接电话，我们几乎不用邮件，我们要邮件就变成外企风格了，所以几乎不用邮件。我个人认为，邮件主要就三个作用：一、通知；二、存档；三、文明吵架。有了钉钉后，文明吵架也可以退出邮件舞台了。
+
+另外，到1800人的时候，我的面试相对就少了，早期其实面试是我一天比较重要的工作，虽然不一定每次都能到我这，但还是有相当的面试量。
+
+极客时间：早期是2015年吗？
+
+张雪峰：对，就刚进去嘛。后来从国外请了一些高手过来之后，他们面过的我就要面一下，只要到了他们这一级的我都会看一下。
+
+被收购前其实我的面试量已经不大了，反而是收购完之后要重新调组织结构什么的，那时候也有些面试，但至少被收购前面试不是主要占用我时间的工作。刚说的这些工作差不多就要搞到下午了，上午是搞不完的，因为光项目日报和提出的问题风险，我就要看好一会，业务数据我基本心里有数。
+
+其实还有一个常规的事情，饿了么基本上每天或多或少有一些告警，是真的有异常，但是它不是故障，我就要看一下。
+
+从我加入饿了么第一天起到离开，我还是一直放不下这件事，其实按道理讲，这不应该是一个典型CTO在团队到这种规模的时候的一个常态，但是没办法，因为我们的迁移改造，包括百度外卖的PHP没有全部迁完，其实被收购前我还没有完全搞完。
+
+除了这些，另外就是参加公司的会议，也就是例会。一般业务找我开会我不去的，之前业务他们开会我也去过几次，就是念PPT，会议一开就4个小时，轮番汇报。到后面团队越来越大，组织也有点臃肿，甚至有点腐化，所以后来我就不参加单个业务的会了，除非他们出了状况，出了状况我们一般私了。
+
+我一直Follow不知道谁说过的一个原则：大事小会，后面我再补一句：小事钉钉，最好没事。做到极致就是当我这个角色不存在。当然了，有些会也不得不去，比如：技术准备和业务Battle，当然更多时候是和产品“吵架”，他们会拉我去站台；又比如：技术同学有个Idea，希望布道全公司，拉我到发布会现场伪装成CTO明令要求等等。
+
+回到那句话“大事小会”，其实在大会上吐两句槽的一般我都是忽略的，不是特别重要，真的出事，没时间让你开会吐槽的。还有一种会，类似上面提到的，他们拉着我的虎皮去参加一些会，让我去现场压某个团队，或者要发起一个事情，需要我在现场，不一定要说话，就是要听一下汇报。
+
+另外还有周会，我这边也是开的，但就我自己印象，除了第一次开会主要say hello，之后到我离开前最后一次周会，我从没搞过一次“各团队例行汇报”（注：疫情期间远程周会汇报各团队安然无恙除外）。我们都是这种模式：第一步，提前征集议题，一半以上是我提的；第二步，未结议题跟进或关闭；第三步，新议题讨论和决议，决议不了的，专人跟进；第四步，散会，不到点也散会，或者大家说点八卦。
+
+其实我不喜欢开会，也不太喜欢听汇报，这种事我还是喜欢通过Email或钉钉，就是事务性工作尽量不开会，所以到了1800人的时候，很多员工只知道我，但从来没见过我。
+
+我最后去办离职的时候，那位 IT 同学跟我说“我第一次见您的面”，我感觉很惭愧，我说今后反正微信上有你，到时候联系。我跟很多同事都是这样，到了那个规模，对基层的关怀可能真是少了一点，覆盖一线几乎不可能。
+
+我盯一线只有一种可能，就是出故障的时候，我盯着工程师，但我不会去罚工程师。我们所有的惩罚，都是对至少是闹出故障的工程师的Leader，然后一直到VP，或到我的D（Direct Reports，指直接汇报给张雪峰的人）。
+
+阿里进来之后，我就不只在故障的时候跟一线工程师有联系了，因为阿里经常会搞圆桌。我在阿里最后1年，圆桌会议开了无数次，在北京、上海都开过。
+
+其实到1800人的时候，我晚上回家基本可以在8点左右，有时候更早一点。如果这一天没有什么特别的事，我也不会去发起一些会议或钉钉群，我就看看技术资料，比如说写点小程序，因为那时候毕竟在其位，需要了解一下前沿。
+
+当然这一天工作中会有穿插的就是同学找我聊天，尤其在被收购前，大家都很紧张、很慌。虽然我自己也吃不准我的命运。但是我比较笃定，即使我感觉需要我让位，那我就直接让位，人就是这样，你有预期了，再碰到就不会惊慌，人的惊慌或者惊喜都来自于你根本没料想到，比如我在第三家公司时的那次晋升通过。所以那段时间，我的主要工作之一就是安抚大家。
+
+极客时间：所以还是有非常多沟通的事情，是吧？
+
+张雪峰：对，但很少到毛细血管，这是我一个做得不足的地方，我当时没想到圆桌这样的形式。我在公司收购百度外卖那段时间，因为要安抚北京团队情绪，经常开All Hands，我在北京开的最多的就是All Hands。有时候下面部门会议，会搞些花样，比如月度新星这种活动，找我去颁个奖什么的，但这不算常态。从本质上说，我这人不喜欢暴露在大庭广众之下，很多时候没办法，被逼的。
+
+极客时间：在阿里搞圆桌主要是什么样的形式？
+
+张雪峰：圆桌是这样的，HR会收集问题放在一个Excel表里，都是大家关心的问题，有些是普遍的，有些是个例的，就是让大家吐槽。我估计是在吐槽的同学里面筛选一部分，然后来跟我圆桌。
+
+刚开始还比较机械，大家做个小游戏，热热身。当然目的很简单，就是让我“出丑”，这个出丑是比较温馨的出丑，绝不是网传破冰那种。就是调戏我一下，然后活跃一下大家的气氛，不要那么拘束，后面就是按部就班，开始念Excel里的问题。
+
+其实圆桌开得多了之后，就感觉大家也有点提不起劲。因为啥呢？很简单，相似的问题或者我已经知道的问题，我要是之前解决不了，那还是解决不了。我也不能跟大家说，我承诺你几个月能搞定，要是我能解决的事，当场就拍了。所以后来发现圆桌会议，我也就是做一个倾听者角色，让大家知道我愿意听你发牢骚。
+
+极客时间：所以能倾听，在管理中也是很重要的。
+
+张雪峰：对，我在工作中特别善于做一个倾听者，甚至可能不亚于HR。其实员工找我也就是吐槽、抱怨，除了不方便直接说给我升职加薪，就是抱怨不爽嘛，包括晋升失败之后的不爽等等。
+
+极客时间：还有什么是你觉得自己做得不好的地方吗？
+
+张雪峰：还有一点我做的不太好，这是有人给我吐槽过的。好几个同学离职的时候都跟我说，“雪峰，有一点我们认为你是做得很差的，就是不搞团建”，我离职之前，还有人跟我说这个事。
+
+我确实不搞团建，都是单独吃饭的。我搞团建其实很勉强，都是HR去张罗着、劝着我搞，我们也很少去外面的风景区。阿里特别喜欢搞团建，我不喜欢。
+
+我后来反思，这可能跟我性格有关。你别看我现在滔滔不绝，讲话也算利索，抽象也算到位，其实人一多，我还是比较紧张的，虽然到不了社交恐惧程度，但是我确实不太喜欢社交，哪怕是网上社交我也不太喜欢。所以，后来我几乎退掉了所有微信群，可能是我这个人的性格问题。
+
+包括我去百度外卖开All Hands都是硬着头皮上的，其实我是很紧张的。有时候参加一些新闻发布会，有聚光灯的话我更紧张。所以这可能是我不太想做的事，我更喜欢的是单独聊，但是你管组织就没有办法。
+
+极客时间：不搞团建是说你不参与大家团建，还是说你不鼓励团建呢？
+
+张雪峰：我没有不鼓励，就是我自己不搞团建。大家可以说这是我的一个问题，但现在回到过去，我还是不会搞。因为你搞什么呢？要么旅游一场，要么做游戏，但更多的估计还是围着领导转，这样除领导外都不爽，非我所欲也。
+
+我们就搞过一种团建，是HR劝着我搞，叫裸心会，但后来我觉得蛮有价值的，基本都要到凌晨结束。裸心会就是开诚布公，大家甚至在裸心会上对骂，当然是文明的骂，就是平时有不满，有抱怨就说出来，然后最后一个环节是吐槽技术团队、吐槽张雪峰，说这个组织有多么烂，张雪峰做得最烂的一件事是什么，都要提。
+
+极客时间：裸心会上大家都在吐槽什么？
+
+张雪峰：反正各种各样都有吧，当然有些是照顾我面子，但整体我感觉从裸心会来看呢，大家可以给我打70分。
+
+极客时间：但其实是到了阿里才会有这样的东西是吧？
+
+张雪峰：是，到了阿里才有。那次开裸心会，是阿里收购了我们，但是还没有开始融合的时候。因为昆阳有一段时间是保持不变的，他还要在业务上解决两个组织融合的问题，技术融合还是第二位的。
+
+当时搞裸心会，我们到上海淀山湖旁边搞一些节目，他们要我也做节目，我坚决不干，我说你们可以善意地“羞辱”我，但不要通过搞节目显示我菜。这个谈不上我的底线啊，如果大家非要坚持，我也只能硬着头皮上，反正裸心会上就各种平时的抱怨，对公司的抱怨，对技术组织的抱怨，对我的抱怨。这很好，完全达到了预期目标。当然了，最后还是要去解决裸心会暴露出来的一些可以有效解决的问题，否则就纯粹是发泄大会了。
+
+极客时间：像裸心会这样的活动，你觉得对于团队融合是很有用的吗？
+
+张雪峰：有价值的，相当于是一个发泄的渠道，这个比倾听更重要。
+
+极客时间：回到刚才说不搞团建这事，我很好奇，为什么你会对团建旅行很抵触呢？你觉得旅行对一个团队融合来说，意义不大吗？
+
+张雪峰：还是像刚才说的，除领导外都不爽，非我所欲也。我在携程倒是搞过团建，就是大家一起去旅行。我也不会“夹带私货”，给大家讲任何PPT，就是聊聊天或者玩一玩，纯粹的旅游放松，但我感觉我还是会破坏这个氛围。
+
+吃饭的时候，不管怎么样大家总会拘束的，当然说难听一点也有来奉承你什么的，也有让你讲一些段子的，但总体我是感觉大家比较拘束，因为我也说了，这个组织的特点，大部分是比较年轻，我即使能跟90后保持沟通，但是在私下非工作层面，我感觉还是有代沟的，所以我是感觉自己会成为瓶颈，阻碍了大家的兴趣。宁做孤独的灯塔，不做惹人厌的灯泡。
+
+他们下面经常团建，会拍个照回来给我看，都很快乐的。搞气氛我认为我是比较糟糕的，但同学们不吐槽我这点，可能他们认为这不是CTO主要的工作，但我认为这也是蛮重要的。
+
+因为我之前拆解了CTO，“T”这层面我认为我还可以，“C”组建团队还可以，挖掘人才也凑合，技术文化也还说得过去，但是在促进大家更深度的情感融合方面，这个是指他们之间，不是跟我之间啊，我感觉差了很多。
+
+因为我要开团建会，更多不是要我去跟我的直接汇报线沟通感情，跟他们沟通感情我每天喝一次咖啡就行了，更多的是促进他们互相之间的了解。
+
+有一次他们说，峰哥，我们今年团建费比较多（公司官方团建费很少，主要靠会议迟到赞助费），要不去泰国搞一搞？后来我也没同意，我说你们要去日本，要去泰国自己去，但这些钱就不够分了，因为他要分到他的团队。我说一定是按人头分，你别跟我要多少钱，没钱。
+
+其实饿了么以前团建费是比较少的，除非是搞一些特殊活动，我会去向Mark申请。搞团建、促进感情方面我投入不多，但是我们在技术文化方面，是很舍得投入的，你看我们Hackathon其实每年都要花很多钱，这也是吸引人才嘛。我们第一年就是全部大学生参赛，内部员工不允许去参加的，那次我感觉大家被带起劲儿来了。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/11CTO要给自己找backup.md

@@ -0,0 +1,61 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            11 CTO要给自己找backup
+                            极客时间：我听到很多人都说你会特别Care找替身，找backup这事。
+
+张雪峰：先说一点：backup这事，指的不是替身，而是替换或超越。首先，我自己必须以身作则，否则自己老在这位置上不挪窝是不行的，这样哪有后浪出头的机会？说到招人，你首先要招自己的backup，先别去招你汇报线，别去想要蚕食多少业务，虽然大家都想把地盘做大。
+
+这是管理层的职责，很多人是抵触，甚至明知道老板在暗示他找backup，他是坚决抵触的，就感觉自己位子不稳了。
+
+我跟HR规划过我的backup，我也跟几个同事说过几次，当然不是跟所有人都说，怕引起大家的不满。我自己第一级的backup，其实并不是我认为最有潜力，或者最完美的，反而是在职级稍微低一点的中层，在这一层的年轻人，包括以前从交大出来的老员工，我反而是最看重的。还有就是第三层，更年轻的、接近95后也有我特别看重的。
+
+我的这些backup里面，第一级backup说白了还是老气了一点，他们的能力、视野是够的，影响力也够，但是冲劲不足。第二梯队呢石佳宁（离开前负责中台技术团队）是首选，其实我是把石佳宁作为接班人培养的，他有这个综合能力，而且饿了么的业务他几乎都做过，除了APP没做过，物流没直接做过，但他和物流交互很多，他也很熟那一块。
+
+再下面一层级就是工程师上面的直线Leader，一线Leader里面也有我特别看好的，接近95后的，可惜不少去了拼多多。这一梯队中，首选就是许红涛（先后负责商户开放平台、企业订餐），后来我推荐他去一家朋友的独角兽公司，朋友是圈内老炮，眼界非常高，但自从和红涛聊过一次，就特别欣赏他，虽然之后知道红涛想创业，但直至今日还给他留着位置，期待红涛回心转意，哎，我都不知道自己更希望红涛创业成功呢还是不成功（笑）？
+
+极客时间：你选backup的标准是什么？
+
+张雪峰：人品这些基本的我先不谈，我首看的是潜力。第二个看是否在业务做过，这很重要，也就是说你今后做CTO一定要在业务线做过，当然懂一点基础设施更好。因为我自己职业生涯是先做业务，再回过去搞基础的东西。
+
+极客时间：你认为什么是有潜力？
+
+张雪峰：我认为的潜力（不等于天赋、能力、努力），就是“拔苗”试一试，假如你给一个人更高的职级，或者给了更大的Scope（领域），他最后搞定了，那就是有潜力。虽然大家都说看人要准、要有一定前瞻，但这个准和前瞻很难，除了受个人喜好甚至偏爱的影响，还有是否 Match 的更大挑战。这个类似幸存者偏差，大家往往很难理解为何常规认为的 Better/Best 输给了 Worse/Worst，适者生存、物竞天择才是这个世界不变的规律。
+
+当然我说的“拔苗”有一点冒险，因为你只能试。我们其实也试过很多同学，就是拔一下，如果做成了，那晋升就水到渠成。
+
+但也有另一种情况，有些同学可能我开始感觉他不是那么有潜力，但是有别的事情证明他有潜力，比如说P7岗位要晋升P8，要待两年才有资格，但有同学入职半年就提名了，最后还晋升成功，说明可能是我们没看到这颗“金子”，这种情况就是通过不常规的晋升看到一个人有潜力。
+
+正常晋升就是干两年正常晋升，再干三年再晋升，这种就是Normal，这种我认为不能叫有潜力。
+
+所以我说的能做backup不是按部就班过来的，而真的是我们拔了一下，结果他不负我们所望，还有一种就是你开始看走眼，但晋升成功的，这两类都是有潜力。但按部就班的我认为不是有潜力的。可能不够抽象，但我就是这么来看且实践的。
+
+极客时间：backup必须要设定几层吗？我可以这么理解吗？
+
+张雪峰：也不是，我永远是看潜力。就是说第一位是看潜力，第二是要做过业务，基本这两点过了，其他什么技术、视野，这些都可以锻炼的，因为有潜力，我相信他就有视野，我也不看他什么背景。
+
+潜力的表现还有一个是你要笃定，你自己要自信，然后眼光要准，你愿意跟这家公司走下去，不是说因为感情的原因，而是你看好这家公司，有眼光也是体现潜力的一种。眼光不一定CEO才有，有些人职级很高，但他没有眼光，就是守着这一块地，所以潜力也包括眼光。很多冉冉之星都是从基层做起来的，所以，做过业务很重要，要经过锻炼甚至磨练。在饿了么技术团队，我印象中，没有比石佳宁受过更多业务磨炼的同学了。
+
+其实我不太建议校招生直接去做中间件这些东西，或者做工程算法（AI算法除外），他们还是要去业务团队先磨练一下。
+
+极客时间：刚你说到接近95后的backup，你会不会觉得95后或者更年轻的同学，虽然有潜力，但是可能不够沉稳，或者说比较急躁呢？
+
+张雪峰：还好，还是要看人。我规划的第二、第三代backup，都是比较沉稳的，因为第一、他们经过业务线的考验；二、他们有潜力；三、情商也还可以。沉稳不沉稳这个跟职级无关，跟年龄是有一定关系，但过于沉稳可能就少了锐气，我认为人大概率到了40岁以后，确实锐气锐减，有锐气的很少，创业除外。
+
+像左耳朵耗子是一个，还有涛思数据的陶建辉，我本来想请他来给同学们做讲座，讲一讲50岁还能做程序员的话题，为了让大家对饿了么能够更有黏度。但他们这种人很少，大部分到了40岁，雄心壮志就少了。要么就是还房贷苟着，要么就是自己出来再冲一把，因为到45岁你基本没机会了，到65岁就要退休了，这一辈子可能都没机会了。
+
+极客时间：这是你对backup的理解，对他们有一些评价标准或者要求，那再往下一层，那对于普通工程师来说，你觉得一个称得上优秀的工程师要有什么特质呢？
+
+张雪峰：我认为一个优秀的工程师必须得纯粹，不要有杂念。“纯粹”这个词怎么解释呢？就是要专心把自己这块事情做好，尽量做扎实，自己尽全力，不过多关注利益。因为有些同学他做事情是有一些想法的，人总有欲望，要么是为了名，要么为了利，要么就是地盘扩大。所以要做到纯粹，就是要没有杂念，或者没有那种显性的杂念，非常难。
+
+我前面也说过，老员工薪水很低，但他们也没有什么抱怨，就是把事做好。比如说兰建刚，一开始我只是给到高级经理，后来是通过晋升，到总监，再到高级总监，高级总监他还差一点没晋升过，因为建刚演讲简直一塌糊涂（笑），后来是我跟Mark好说歹说，我说这个你必须让他过，后来才勉强过了（要放在阿里晋升场，这几乎是不可能的事），但建刚自己倒无所谓，他团队好多技术强、够纯粹同学，都对晋升无所谓，我也无语。
+
+换句话说啊，对于你在意、喜欢的事（自由、开放、洁癖、架构等），极度有所谓，对于你不在意的东西，极度无所谓。
+
+人人心中都想追求完美，但有时候因为你对其他事情有欲望，就可能分心了，有时心里会敲锣打鼓，比如出故障的时候，你可能会想，到底应该选什么，是甩锅保命，还是承担责任？很多时候，故障能看出一个团队和一个人的担当。对技术同学来说，勇于承担责任也是一种纯粹，只要是我负责的、我在意的事情，出了问题一心去解决就好。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/12CTO的艰难时刻：差点引咎辞职.md

@@ -0,0 +1,113 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            12 CTO的艰难时刻：差点引咎辞职
+                            极客时间：你去饿了么也属于空降的领导，刚进去会遇到什么挑战吗？
+
+张雪峰：其实大家都专心做自己的事，我是没有感受到所谓的火药味或防御性。第一天我担心是有防御性的，但我一直没有体会到，只体会到他们对技术的追求，所以刚开始团队这块倒没什么，我主要遇到的挑战就是宕机，2015年那个夏天，我差点要引咎辞职，七月份各种故障纷至沓来。
+
+极客时间：到引咎辞职这么严重吗？
+
+张雪峰：宕机给我们造成的心理压力太大，那时候饿了么单量已经很大了，真是水深火热。我刚进去其实压力不大，因为我岁数大，大家都比较尊重我，Mark也比较尊重我。但三个月后我也开始被他挑战，被他骂，骂得很有道理，就是我们团队做得不好。
+
+七月份我们基本一周要宕机一次，有些感知得到，有些感知不到。那时候我基本都是最后一个离开公司，都过零点的，因为我要确保没问题，其实也是有点拖延时间，就想怎么样才能完全破解。
+
+当时觉得挺对不起公司的，而且Mark一开始是骂，到后来他也知道，我比他更着急，他也不骂了。所以15年那个夏天我真有可能就离开饿了么，后来反正不知道脑子怎么抽了筋，最后也没有提交引咎辞职报告。
+
+当时我进来半年，也招了一些同学进来，跟新老团队融合得还可以。如果我选择离开，那这些人怎么办？所以后来想想还是考虑兄弟之情，咬咬牙硬挺过去了。
+
+那时候就感觉自己真的快扛不住了。Mark有时候说两句，业务部门也会吼，但是都有尺度，但一线人员才不管，一线那时候把我们骂惨了，天天被骂成狗屎。
+
+以前有个软件，比现在脉脉还要疯狂，叫无秘。脉脉职言区有时还是有顾忌的，因为有商业公司在运营，无秘是完全无官方运营的，就是一个畅所欲言的地方。那时候一天被骂得最多的就是：“拜托你们能不能招几个好点的网管？”。
+
+一线说“招几个好点的网管”这样的话其实很朴实，他们觉得这些搞技术的都是天天吹空调、敲键盘，我们销售还要扫街，还要和美团“白刃战”，体力脑力兼有，然后一宕机还要被商户骂。
+
+商户去骂也是对的，因为高峰期过了，消费者退单，宕机意味着做出来的饭只能倒掉，他也不知道要送给谁，浪费粮食啊，真的是很惨痛的教训。那时候大家可能认为赔商户钱就解决了，但其实商户心疼的是饭菜，眼睁睁看着好好做出来的几十份、上百份全部倒掉。
+
+我们还要赔消费者，因为餐没送到。赔消费者是发红包，发红包的意思是说，这次我们宕机，下次你不要抛弃我们。除了商户和消费者，我们还要赔外卖小哥，因为小哥不能白跑。还要照顾销售的情绪，倒不用给销售赔钱，但我们要赔礼道歉。那时候真的很迷茫。
+
+后来我们经常去一线调研，我也要送外卖的。一开始他们还不太敢说，我说咱们就当兄弟，有点江湖味，他们会给一些反馈。那个时候我是体会到兄弟之情，一线真的很苦，他们说得好听叫销售，但其实就跟扫大街的清洁工没什么区别，甚至更惨，清洁工还知道他是有固定任务，基本不会出问题。但销售要承担风险，万一宕机他要想怎么去赔礼道歉，甚至发生过有的销售快要给商户跪下去道歉。
+
+极客时间：宕机的问题这么严重，你当时心里感受应该挺难的吧？
+
+张雪峰：对，压力过大，好在没有到睡不着觉的程度，但第二天肯定又会想这些事。
+
+虽然心里难，但我要能控制住情绪。我的个性还是能控制住情绪，因为确实是自己和团队要扛的责任，团队已经够拼命、够努力了，这个时候你去压团队也没用，我也不可能再去招一批人，招人也救不了火，而且招来的人还得磨合，所以只能是自己去想各种对策去弥补，主要还是靠时间。
+
+绝顶高手是能控制住情绪，也能很快能消化掉，我是能控制住情绪，但我不能很快消化掉，我需要时间来稀释，以及想一些辅助手段去弥补。那时候，每天晚上为什么都要过零点才走，并不是说我必须最后一个走，就是待在公司去想一些问题。每天坐在座位上，电脑也看不进去，就想这些东西，所以主要还是靠时间吧，把这个不好的情绪稀释掉。
+
+极客时间：你觉得自己是一个乐观的人吗？
+
+张雪峰：对，我是偏乐观的，因为不乐观没法压制住自己的情绪。如果你是悲观又要压制情绪，一定会崩溃的。虽然我个人是乐观的，但是我对工作或者像安全性、稳定性这种事情，我会做最悲观准备，或者说设定一个较低期望值，这样不至于灾难或者故障来之时手足无措。因为很多时候一个人崩溃，是他根本没想过这件事，或没到他的期望值，才会出现很大问题，感觉难以释放。
+
+从我的角度，这个期望值大概就是时间，时间可以解决这个问题。但首先你要能控制住情绪。
+
+极客时间：后来宕机这个难题是怎么缓解的？
+
+张雪峰：硬挺过来的，八月初就缓解了。当时主要两个地方：PHP、RabbitMQ有问题。
+
+我们当时用了一个开源的消息组件叫RabbitMQ，这是个巨坑，不是说它软件本身不好，而是我们没有能力完全驾驭。另外，我们当时的PHP水平也还算可以了，包括后来我们找新浪的人（新浪用PHP比较多，饿了么也找过新浪PHP大牛尝试破局），他们也搞不定。PHP底层有引擎，当时每周一次的故障，几乎都是这个引擎带来的连锁反应，我们没能彻底搞定，然后大家都去读C的源码，赶鸭子上架，源码是能读懂，但就是搞不定，这东西可不是你加一句两句代码就能彻底解决的。
+
+后面我们就用了各种work around，你知道work around就是绕过去甚至很ugly的办法，或者做很多补丁。其中一种补丁的学名叫补偿，比如你这个订单没过去，正常就丢了嘛，但丢了很严重，我们就设置个轮巡机制，有个Job，假设本来订单是5秒内响应，现在就是1分钟后发现有个订单漏了，再给你搞一次，用这样的方式（甚至包括人肉），做各种补救措施、补丁工具等。
+
+物流宕机最可怕，因为我们这个业务是强耦合，不可能松耦合，就是要高内聚。物流宕机当时我们怎么做？人的智慧真的无穷，刚开始大家就用QQ群解决。因为我们类似广域网下的无数个局域网（不像淘宝，淘宝全国任何一地商家都可以服务任何另一地用户），我们可以划片区。他们那个QQ群就是骑手、老板、调度经理等人组成，骑手就送这几个商户。
+
+比如说物流宕机了，但这时候订单是有的（商户挂掉那就没机会了），老板能做出餐，但是没有办法传递到小哥怎么办？小哥在QQ群里说“我没接到单，你有多少单了？”商户说“我已经接了10个单，你快来。”然后就在QQ里面传单号。那时候微信还不怎么流行，小哥还是喜欢用QQ。但后来宕机问题解决，终于可以下线QQ work around了。
+
+极客时间：有点曲线救国的意思。
+
+张雪峰：是这个意思，后来我发现物流系统还有个很大的问题，搞物流系统这批同学，就是另一类极客。饿了么刚开始拆分服务，物流拆分得很夸张，直接同步变异步了。我说你们犯了一个错误，叫“为了异步而异步”。
+
+大家以前的代码（交互）尽量都是一路撸到底嘛，直接写完，这个叫单体。后来搞微服务就要拆开了，结果他们不光拆开，拆开之后，还要用消息通知。我举个不太恰当但大家明白意思就行的例子，比如说算工资，本来可以直接算出来，他们非要先送一个你的职级，再送一个你的社保基数，然后送过来之后还不是马上给你，你要自己去取，我只是通知你有这个数据了。你取过来之后慢慢算，算完之后再推给另一个涉及工资计算的模块，诸如此类。物流同学就是用类似方式，他们真的把异步做到了“极致”（饿了么价值观：极致、激情、创新）。
+
+但是他们做异步的初衷是什么？是因为物流的量很大。以前宕机是因为量很大，用同步的话服务器撑不住，所以就改异步。他们说至少可以缓和五秒钟，但后来我发现这五秒钟没意义。
+
+我自己也体验过，比如我点个外卖，提交订单之后习惯性去刷一下，看看商户有没有接单，然后过一分钟看看骑手有没有接单。还要看地图，有时候看到小哥明明经过我这了，怎么先去送另一个人了？可能很多人都有这样的疑问，这个不能怪骑手，也不能怪系统，有各种原因，此处暂时不表。
+
+大家都会去刷，后来我们发现用户在饿肚子时的心理承受能力就是三到五秒（淘宝、携程没这问题，大家对订单或物流状态变化的容忍度高很多），你是通过异步让这个订单不至于当场爆掉，但你延后五秒之后，堆积起来也很厉害，东西多了之后，最后还是爆掉，你只是让用户前五秒感觉系统没有宕机，但最终结果还是宕机。最后我们异地多活搞出来，几乎就没有大的事情了。
+
+极客时间：其实这一次困难挺过去之后，后面再遇到难题，相对来说你就比较从容了。
+
+张雪峰：对，那时候我自己心里有障碍，不好过去，至少刚开始不好过去。我和老婆说，估计要在公司旁边旅馆住几个月，直到彻底解决宕机问题。那时候，大家也看到我的焦虑，他们也竭尽全力，但宕机这个事情你不能去硬搞，比如每天都去揪每一个（可能引起宕机风险）模块的每一行代码写得怎么样，这个会出乱子，也极其耗时，ROI 极低。在当时那么紧迫时局下，我只能用另外的方式（如：局部技术改造、局部架构升级等）去缓解。当然了，中长期解决方案还是团队整体架构能力和代码质量提升，这里先不展开了。
+
+那时候还没到根治的时候，因为当时不要说异地多活了，灾备还没有呢，所以只能去缓解。你如果要根治下猛药，那我那会真的可能实现了CTO里面“O”的价值，但这个就是负面价值了，会导致公司出问题。
+
+如果那次我引咎辞职，汪渊是可以临时顶上去，但真的，就不说团队可能散架吧，后面凝聚力肯定会有大麻烦，因为汪渊已经去搞产品了，大概率还得再找个CTO过来。
+
+极客时间：除了这个对你来说是个坎儿，还有没有其他的艰难时刻？
+
+张雪峰：还有一次是在阿里，出过一次事故。当时就是异地多活出了事情，理论上异地多活能切的，但是因为一个开源组件的问题导致出了一个大事故。
+
+我后来也反省，我是有责任的，因为这个组件当时做过一次交接，本来是在中间件团队，后来交接到另外一个团队。但交接的时候，只做了个口头交接，没有立字为据，没有指定说这个就是你来管，这也是我们当时不够精细的地方。所以最后很难判责，确实判罚谁也不好说。
+
+而且其实任何故障都会有端倪，没有无缘无故的故障。在那次事故发生前，其实有一些端倪了，只不过比较隐蔽，只有极少数同学发现了，但他们也没意识到持续堆积会造成重大问题。
+
+后来我们复盘发现，当时出了故障，不做切换反而不会引起大错，最多就牺牲一小部分流量。但是按照SOP（标准作业程序），确实应该切换。恰恰是这个开源组件命中了一个Bug，所以导致切换引起了风暴，细节我就不多讲了，但其实事故发生前就有端倪了。
+
+出了这个事，我跟建刚商量，我说建刚你做好准备，扣你全年的奖金，我自己降一级，我们跟公司主动一点。跟公司汇报完了，昆阳火比较大，他说你凭什么自己申请降级，你没这个资格要求自己降一级。他意思是说你自己感觉你有担当，但他们（包括CEO、CPO）不认为我这时候这么做是合理的。
+
+他们灵魂拷问我说，“雪峰，我知道你有担当，你想帮团队扛下，你想保住他们，但是你有没有考虑过，进了阿里之后，如果一线工程师不为一个Bug负责，而且是他已经看到可能有问题，只是没有警觉，那你认为今后组织再扩张10倍，还能不能Run下去”，他说的是有道理的。他认为我是江湖气，当然我是有一点，但其实我也感觉自己没做好，不完全是为了帮团队顶锅。
+
+后来我就只能出面去跟一线工程师谈。那位一线工程师对我们有汗马功劳，是一位非常优秀的员工，只是因为组织转变、汇报关系转变，包括责权不清晰等等问题，他自己也郁闷，所以就没怎么上心。我跟他说从结果角度你要承担责任，你要承担工程责任，我承担管理责任。
+
+他认这个理，但是他也感觉比较委屈，最后他跟我吃顿饭，说自己也想通了，我说我对不起你。我们对他有一些小的处罚（不是劝退），但后来他主动提离职，其实相当于我劝退他，我认为这也是对我的一个考验，这也是我另外一道坎儿。
+
+当时如果这件事被披露到网上，工程师们肯定会非常愤怒，说不应该惩罚一线工程师，这全应该你们Leader来担，但一线工程师在阿里也是要担一定责任的，不会让你降级或离职，但至少会对你的年度绩效有影响，比如绩效不能3.5，不能参加晋升，这种处罚也是有。我们也类似，并不是要让他辞职，基本都是通过绩效反映的。
+
+我认为HR说的是有道理的，对于一个组织来说，确实应该这么做，特别是对一个越来越大、越来越正规化的组织，是应该这么做，否则没有规矩不成方圆，我再心疼他，他有再大的汗马功劳，也得这么做。跨过这个坎，对我来说也很不容易。
+
+极客时间：我可以理解劝退别人这件事对你是一个坎儿吗？
+
+张雪峰：不是，我也劝退过不少人，但我感觉劝退我认为几乎没过错、又曾立下汗马功劳的优秀同学，是一个坎儿。
+
+极客时间：如果那个时候不是在阿里，而是在没有被收购之前，遇到这样的事情，你会怎么做？
+
+张雪峰：没有收购之前的话，可能我就跟Mark说我降级，Leader他们就象征性的处罚，因为这个事情扯不清了已经，没有立字为据。所以责权不清这是我要反思的，也是我的责任。
+
+所谓协调，相当一部分都是这类问题。表面看，这可能是件小事，组织架构有调整我也知道，但我在规范设计或制定上有漏洞。其实PMO已经帮了我很多，他们制定了很多细节，但我在这件事上确实有责任，而且引起了很严重的故障。但经历过就有收获嘛，你没经历过，后面还是会有类似的情况发生，尽量不要在同一个地方犯两次错。所以，我都是一路犯错过来的，一路被挑战。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/13大的决策与难做的决策.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            13 大的决策与难做的决策
+                            极客时间：列举一下你在饿了么做得比较大的决策？
+
+张雪峰：第一个大的决策，我冒着风险把兰建刚招进来了。我和他一面之缘，江湖上名声不显，就是因为他做过电信级软件，感觉可以聊一聊。建刚当时话不多，如果滔滔不绝的我肯定要打个问号的。我那时候没得选，之前谈妥的那位跳票了，建刚是跳票那位强力推荐，这个你可以认为是赌博，但有时候决策就是赌博。沟通或许看缘分，但特殊时期的快速决策，必须冒风险。事后都证明了一点，这个冒险赌对了：不止建刚自己绝对靠谱，他的个人能力和魅力，盘活了整个 CI 团队（草创的时候叫框架&工具团队）。赌 Leader，实际就是赌 Team，一本万利（笑）。
+
+第二个就是2015年7、8月份，饿了么频繁宕机，我最后没有引咎辞职，这是我个人的决策。后来经历多了才体会到：当时自以为引咎辞职很有担当，实际却是逃避，是对公司和团队的不负责任。换句话说，即使要引咎辞职，也得把摊子收拾干净了再走人（当然了，公司不让你收拾干净直接干掉你，也无话可说）。
+
+接下来就是决定做异地多活，当然这个有皓哥（左耳朵耗子）和建刚的推波助澜。
+
+最后就是，2017年7月份收购百度外卖，我坚决要把百度外卖的技术团队留住。
+
+极客时间：在这些决策里面，你觉得哪一个是比较难做的？
+
+张雪峰：就是我自己的那件事，没有辞职。因为组织上再怎么艰难，我都可以挺过去。包括识人这方面，其实有时候人和人之间就是有一些量子反应，量子形容到人就是两个人精神对上了，产生化学或生物反应，所以这方面我认为还好。
+
+从组织层面讲，事后来看，自己在这方面相对比较笃定：我能够凝聚住大家。当然这个也是事后才能这么说，当时如果做的一塌糊涂，我现在就不可能厚颜无耻在这里参与访谈了。现在不管身在哪个公司，不少同学也会一直找我、“骚扰”我，说你什么时候重出江湖？我说你们说的江湖我可能不太会再考虑了，可能先做点有精神快乐的事。
+
+我认为这样的事做一次可以，再做就有点重复了，现在也有些公司找我，但我认为几乎不可能再经历像饿了么这样跌宕起伏的五年了，人生又能耗费几个五年？我们经历过3家云厂商，都是3家云厂商曾经最大的客户；经历过BAT 3个巨头的入股或注资，或被收购；又经历过一个“土八路”团队从头到尾的“野蛮”生长，所以我也希望分享一些Difference，更多是我认为做得不好的地方，一些教训、失败，或者要去反思的地方。
+
+极客时间：总结你自己做过的决定，你觉得你是一个做决策很快的人吗？
+
+张雪峰：大部分时间是的，我这边名义上是集体决策制，或者民主集中制，一般我还是比较听大家的意见，要让大家说话，有时候他们都“闷炮”一样，我会鼓励说你告诉我这个到底是不是有问题什么的，但最后拍板基本还是我。大部分时间我是直接拍死，或者直接毙掉。
+
+极客时间：你有做过错误的决定吗？
+
+张雪峰：从事后结果看，多了去了。致命的错误我也不好判断，因为这个要旁观者来评判，我自己感觉致命的，就是对公司产生重大影响的可能应该没有，但是犯的错肯定不少。
+
+极客时间：比如让你说一个你觉得相对比较大的错误。
+
+张雪峰：我还是说组织方面吧，我不搞团建，我认为是有错误，就没有让团队之间良好的关系建立起来，后来我发现我不搞团建，导致我后面要付出更大成本，比如我要出面，线下喝咖啡去协调。我应该多搞搞类似裸心会这样的活动。很多时候，组织风险远甚于技术风险，而且是温水煮青蛙式风险，让你不知不觉中出现偏差直至产生重大负面影响。
+
+前面我回答你不喜欢团建去旅游，纯粹的旅游团建我确实不喜欢，我一直认为纯粹旅游不夹任何私货挺难的，我觉得自己是个障碍，是个灯泡。但不搞团建这个倒不至于致命，只是你要付出更大的代价。
+
+如果说可能致命的决定的话，就是我想过引咎辞职，可能对我不是致命，但对公司和技术团队可能影响很大（大概率再找一位 CTO），如果发生，我今天也不会在这了。
+
+极客时间：在做CTO的时候，什么样的事情会刺激你，会让你觉得特别有成就感？
+
+张雪峰：我认为团队有成长，我就有最大成就感。我不能说业务有成长我就有最大成就感，而且我们业务的试错大部分也不成功，这个绝大部分公司类似，当然失败也是有价值的，但是毕竟没有成就感，或者说成就感差一些。
+
+其实，我也说过，要尽可能让大家做自己喜欢的事，希望大家感觉到在饿了么做技术和在其他公司不同。
+
+我们也有同学离开之后去了美团，他感觉好像也没什么不同。但说到“没什么不同”，我觉得有一部分是我的责任，我没有给大家创造出这样的机会，其实我们本身跟美团就有不同之处，我们是一个大学生创业团队。
+
+可能到1800人的时候，职业化的人已经很多了，鱼龙混杂，但在四五百人，就是2015年、2016年的时候，其实大家的“味道”还是不错的，是相对纯粹的。美团你很少看到什么开源的东西，后来硬是捣鼓出几个，我们觉得也不咋地，异地多活更不说了，美团找我们交流过这方面经验教训，他们一直想做、在做但也一直没做成，不过现在有没有做成就不清楚了。
+
+美团他们强在组织能力，我们是强在有各种突出的Leader，或者我们自己给大家发散，给大家充分的自由度。这是硬币两面，是好也是坏，当然没把公司搞挂也算幸运。但是另一方面，我相信有相当一部分同学，他们会认为在饿了么技术团队是值得的，可以实现职业发展上的提升甚至个人精神上的快乐。
+
+但这个对公司，我不能说算是对还是错，因为公司花钱养着你们是以业务为第一的，不是让你们玩技术的，所以这里面要平衡，什么叫“玩技术”，什么是通过技术尝试去做一些支持业务的事，很难清晰界定。
+
+极客时间：刚聊了管理上的各种决策，还想补充聊一个管理手段的问题，听说技术团队开会迟到，你会重罚？
+
+张雪峰：1分钟100块，这个是我定的游戏规则，这不是规矩，规矩变成有点你私人帮派味道，这只是游戏规则。
+
+其实我也不是一定要罚钱，我跟大家说了，你如果预感自己要迟到，你要提前通知我。你不要跟我解释路上堵车，不管你坐什么交通工具，你自己作为成年人，先用高德地图看一下。
+
+原来最早是说提前2小时还是3小时，后来我容忍了一点，提前1小时通知我就行。如果离开会不到1小时，结果你突然迟到，那没有任何理由，当然有时候家里有紧急情况，但钱还是要交。5年半以来，一直到我离职，我所有的会都准时参加，从没有迟到过。
+
+极客时间：这个规则是一开始去的时候就定下的吗？
+
+张雪峰：就是形成例会之后定下来的。我到饿了么，一开始没有开周会。后来我跟汪渊把组织拆完之后开始有周会，应该是2015年还是2016年，记不清了，反正这个规则是所有人统一的。
+
+这点上我老婆对我意见非常大，她都是掐着时间。我去机场、火车站，哪怕去高铁站，我几乎都是提前1小时，我要预留足够的时间。我老婆就一直说，高铁你提前15分钟就行了，我会担心万一排队或者出什么事，在这点上我比较坚持，宁愿我等别人。
+
+这可能跟我一直的习惯有关，这个习惯应该在微软养成的，微软这一块非常严肃，外企这一点确实比民营企业强。在微软大家都比较自觉，这个叫Professional，说的好听叫职业素养，但是后来到民企发现不是这么回事，阿里还算是做得不错的。
+
+极客时间：我很好奇，你会看一些管理类的书吗？
+
+张雪峰：基本不看，因为我的兴趣主要在技术（实际最大兴趣也不是技术，后面会提到）而不是管理，你可以说我自学成才，也可以说我不自量力。但其实也不完全是自学，因为管理实践本身也给了我一定时间，虽然最后的组织扩张规模较大，但也用了近3年时间，从几十人到1800人逐步增长起来。如果说饿了么今天30人，过一个月就变300人，以我当年的能力、阅历、视野，不一定能Hold住，速度太快了。
+
+我印象中可能翻过这类书，但绝对没完整看过。借用一句话：那都是很好很好的，可我偏偏不喜欢。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/14不够坚定：异地多活没有一步到位的遗憾.md

@@ -0,0 +1,95 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            14 不够坚定：异地多活没有一步到位的遗憾
+                            极客时间：饿了么异地多活一次成功算是互联网技术圈挺浓墨重彩的一笔，当时你们决定做这件事之前，经历了一个什么样的过程，可以讲讲吗？
+
+张雪峰：2017年之前，整个公司所有的业务系统都是部署在北京机房，服务器大概有四千多台，另外还有灾备的机器是在云端，都是虚拟机，大概有三千多台。当时我们峰值的业务订单数量已接近千万级别，但是基本上北京机房（IDC）已无法再扩容了，也就是说没有空余的机架，没有办法添加新的服务器了，必须再建一个新机房，于是我们在上海建了一个新的机房。
+
+做多活之前，其实这里面有一个失误（严格说不算失误，法不责众，国内几乎皆如此）。当然这个失误我认为大部分团队可能都会犯，就是先搞灾备，不敢一下子上异地多活，没能一步到位。其实当时我也提过“我们是不是一步到位”这个问题，虽然外界感觉饿了么一步到位了，其实我们之前还做过一个灾备，花了不少钱。
+
+极客时间：所以一开始先做了灾备，才做了异地多活对吧？
+
+张雪峰：对，这是常规路径。中国绝大部分公司都是做了灾备后才想做多活，当然能不能做成另说，有的最终没做成，或不敢做，或者内部阻力很大。
+
+美团当年就没做成，现在有没有彻底搞定异地多活我不太清楚。其实美团技术底蕴挺强的，因为跟着王兴早期创业的人不少，包括美团还曾做过美团云。只要做过云，哪怕这个云再烂，都储备了一批做基础设施挺强的人，这不是一般公司技术底蕴能比的。但是美团业务太强势，停几个月业务需求，或只能做些无关核心的边角料需求，不可能的。
+
+饿了么好在技术这块拧成一股绳，基本就是我一个决断声音，说难听点也是一言堂，或者我跟团队即使吵得再凶，他们再挑战我，但最后出去都是一个声音。我跟他们说，你们当场挑战我，都没问题，我也无所谓面子，但是既然我们吵架吵出结果，你就不要再回去反悔，不允许反悔，你跟团队反悔、抱怨也是不允许的。
+
+曾经有一个同学，当场同意，回去又开始磨磨唧唧，在群里乱发，这个不行那个不行。哪怕这件事事后证明错的（谁能在结果出来前证明这是错的？），在当时你就得错到底，证明它是个错也是有价值的。更何况，异地多活最终一次上线成功，之后更是挽救饿了么线上系统无数次。当初有异议的同学，也包括外部知道这事但并不看好饿了么技术团队能搞定的同学都无话可说，虽然最初下这个决断有一定赌博成分。
+
+唯一一次美团跟我们做过的官方技术交流，就是我们做了异地多活后。大家知道，虽然我们两家商业上竞争白热化，但技术同学间还可以，大家不敌视，交流比较坦诚。
+
+极客时间：灾备和多活区别是什么？
+
+张雪峰：灾备什么意思？灾备是我有一套一模一样的系统，每次发布的时候两边都发一次，但是生产的流量或者实际的数据不经过灾备系统，只经过主系统，然后通过数据同步模块全部同步过来。但它有很大缺陷和风险，如果做到极致，全是AI控制或机器人控制（包括发布后各种校验、验证等），理论上精度会很高，但实际很多环节还是人来控制。
+
+我们发布很多，一天上千次，多的时候超过2000次，还有依赖，比如，你发了A 、A.1、A.1.1，这里面只要有一个漏发，可能你生产系统没问题，因为你要用流量灰度切换的，但是那边（指灾备IDC）是没有灰度的，没有流量，今天忘了就忘了，运气好明天又发了这个就OK。但万一来一个事故，流量一下子进来，反而把数据搞乱了，结果不应该发的补贴发了，这也就算了，赔点钱，但是如果数据错了，就大麻烦了。所以它没有经过真实流量考验。很多业务场景，并不是发布系统默认双发或多发就能解决的，还是需要大量人工验证或灰度流量验证才能确保万无一失。
+
+做灾备，你要解决两个问题，备份和恢复，备份和恢复永远是一对的，不能切开。一般的企业更多在备份上花功夫，这只做了一半，不常态化做恢复演练的团队或公司，已经有太多沉痛教训了。而多活呢，既解决了备份，又解决了恢复问题，因为不需要恢复，数据始终在跑。换句话说就是只要确认是Workable，可工作的，就可以了。
+
+极客时间：所以在多活之前做灾备其实没必要是吗？
+
+张雪峰：不是，这个要具体问题具体分析的。
+
+当时我们为什么做灾备？因为直接上异地多活，我是有犹豫的。跟我很熟的人会经常质疑我，在公开的会上也会挑战我（鼓励 Challenge Up 也是饿了么技术文化中自由、开放的一种体现），说“峰哥，你当时不应该做灾备”。但我当时的理由是说，中农工建都做了，美团也做了，滴滴也做了，除了阿里系（淘宝、支付宝算一类），他们确实直接搞了异地多活。那么，除了阿里系，在全中国大家想做交易类系统第二只螃蟹吗（根据事后复盘，严格说这并不算第二只螃蟹，而是第一只网格化环境下的异地多活螃蟹）？我说我不敢冒这个险。
+
+所以代价就是你做了一个用处不大的东西，但它也有一定用处，万一被勒索软件盯上了，我们还有一份数据备份，但是从现实意义来看就好像没有太大用处。这个其实也很难评价，就比如说你做各种形形色色监控软件，你投入很多资源搞中间件，应该很有作用吧？但只要没出事，大家可能看不出来，业务团队或CEO估计就更难以体会在这方面进行投入的价值了。
+
+所以，在国内有一个很怪的现象，这确实跟发达国家不一样。在国内，不管什么行业，救火英雄永远得到最大赞扬，幕后英雄却无人问津，导致很多真正牛逼的人、防范于未然的人，反而委屈地走了。我在饿了么，尽可能去扭转这个局面，但也没有完全扭转过来。因为你很难界定什么叫防患于未然、什么是因为基础设施投入而带来的巨大价值或避免的巨大风险。
+
+在技术决策上，这是我的一次偏差，但后来还是做了异地多活，当然皓哥（左耳朵耗子）和建刚他们让我坚定了决心，我当时不是反对，而是有犹豫。
+
+极客时间：你不敢下决心搞多活，具体的原因是什么？纠结或者犹豫的点具体是什么？
+
+张雪峰：我吃不准中间件这个团队能不能承担并搞定（除淘宝外）这种规模（日均常态千万级订单）下的交易系统上去实现异地多活。更何况，异地多活几乎只有一次上线机会（最大风险不在上线后稳定性保障，而在多活节点间的数据错乱），不成功则成仁。
+
+只不过后面我下了决心，我们也不用立什么军令状了，如果干砸，从我开始，核心团队在收拾完烂摊子后（这是15年夏天那次张雪峰快扛不住想引咎辞职的挣扎后，对责任的全新理解）全部下台。
+
+做异地多活的话，业务要耽误三个月，接不了涉及核心系统的大需求或大变更，业务部门压力非常大，我要去说服。而且上线后如果出问题，那就是致命的问题（数据错乱），因为数据是分开的（多个机房）。我们原来就一份数据，宕机了可以恢复，至少数据不会乱。所以宕机不是最可怕的，就怕你连宕机的机会都没有（之前提到的安全问题类似），数据错乱或丢失，是最可怕的。
+
+如果按我对自己的要求的话，这件事我认为算是一个失误，说得好听点叫偏差，应该一步到位搞异地多活。因为做灾备也投入很多钱，也有媒体说钱打水漂了。但这是事后诸葛亮，我当时也没这样的勇气，因为确实饿了么那时经不起任何大的波浪。虽然这是给自己找的理由，但我感觉如果要求苛刻一点，确实是一个不正确的决定。
+
+决定做异地多活之后，当时找了毕玄、阿里云交流，但是后来发现不能直接用阿里那套（所以前面提到，不是国内第二只螃蟹，是真真切切第一只），因为阿里是适配全网应用，淘宝是没有网格概念的，三亚和哈尔滨是没什么本质区别的。但我们不行，我们是一个表面广域网实际却由无数局域网构成的特殊业务网格，而且我们网格之间是有重叠的，还比较复杂。所以后来决定只能自研。
+
+即使这样，我们第一批上线的异地多活还是把物流落下了，这是后话。
+
+极客时间：如果现在来选的话，直接就搞多活了对吗？
+
+张雪峰：对，如果我回到当年，我就知道这个团队是能承担这个使命的，肯定直接搞多活，当时我也不是太有底气。如果直接搞多活，也能省好多钱了（指投入到腾讯云做灾备的钱）。
+
+极客时间：异地多活当时做完之后，其实效果还是非常好的是吧？
+
+张雪峰：是的，这件事我最为团队骄傲的，不是说异地多活后面帮我们挡过很多以前挡不过的灾难，而是我们有惊无险一次切换成功。因为一旦切换不成功就是灾难，打补丁都很难（数据错乱比宕机更可怕），核心团队散架（士气打击）、我直接下台（业务问责）几乎是必然的。
+
+支付宝有一次严重事故，宁愿宕机不敢切换，就是因为不能出现一分钱差错，这个简直就像银行卡里面出问题一样，一分钱就致命，所以其实当时我不是很有信心能一次搞定，异地多活又是做得跟阿里不一样套路，如果真出事，毕玄、阿里云也帮不上，都是我们自研适配的架构，那一次，真的是大家连续几天，彻夜不眠。
+
+打个不恰当比方，双十一或618出事，最多是稳定性层面故障，舆论压力大但不至于对公司产生致命影响；但如果异地多活切换出事，舆论初期或许感觉不到，但一旦短时间不能修复（数据错乱，时间越长错乱会以几何级数增长），对公司绝对是致命影响，CTO 中 “O ”的价值倒是体现出来了，超级负面价值，或许应了我之前说过的一句话：你可能连宕机的机会都不会再有了。
+
+极客时间：你刚刚也说到第一批上线异地多活，把物流落下了，这个是什么事情？
+
+张雪峰：后来我反思这也是我另外一个不够坚定的地方，也不能说我心软吧，就是不坚定。因为当时物流业务老大，也是联合创始人康嘉，还有技术负责人刘昊旻都犹豫了，问我能不能把他们放第二批？物流出问题，他们都得“跳楼”。
+
+但这样就等于帮物流填了个临时坑，却为整个技术团队挖了个更大的坑。后来我们要兼容第二批（其实第二批就物流，只不过物流涉及系统太多）上异地多活的物流，在这期间，要随时保证物流那边的顺畅，就做了很多开关，然后我们中间件团队、架构师团队还有PMO团队，把杂七杂八这两套东西并线。如果是两套业务系统并线还好一点，只要切个数据库就行了，但这两套异地多活很麻烦，有一堆的风险要考虑。等于我们维持了几个月的“大部分多活+物流非多活”并行，切换时又胆战心惊地担心物流切换出问题，还得切回去继续并行。
+
+我们原来设想异地多活只能一次性切换，因为我们的业务是强耦合的，不像携程，携程机票、酒店关联度不大的，你要订机票+酒店，做个简单聚合就行了，但我们不一样，饿了么是用户下了单，商户接了单，物流就要送单，上下游其实是强耦合（高内聚）。
+
+程序员可能会说，现实业务没你说的那么理想，该强耦合就强耦合，其实不是强耦合，另一个词叫高内聚，该内聚的时候你不要去追求什么微服务那些乱七八糟的东西，就应该高内聚，因为就是一个业务形态，业务才是最重要的判断耦合或内聚的依据。谁（调用方/消费方）也离不了谁（被调用方/服务方），你每次调用都涉及到它，干嘛非强扯开来？没太大好处，当然，可以分开发布算一个好处，但也仅是技术上的好处，不是业务或领域上的好处。
+
+最后送大家一句话，也是我对当年多活改造迁就物流团队的一个教训总结，用英文描述比较贴切：Avoid solving one problem by creating a BIGGER one，希望大家今后都能顺利跨过这类坎，不再重蹈我当年覆辙。
+
+极客时间：你刚刚说美团也想做异地多活是吗？相当于它也是走了常规路线，先做了灾备，再想做多活。
+
+张雪峰：是，美团做了异地灾备。美团现在没有CTO了，在王慧文之前，CTO叫罗道锋，他原来是大众点评的CTO，后来美团和大众点评合并之后，他就做了美大的CTO。
+
+之前提过，我们团队和道锋团队间做过技术交流，美团一直想做异地多活，但规划了几年一直没做成。后来我问了那边相关同学为什么，他们说道锋虽然是CTO，但主要管公共技术，也就是搞搞基础设施、大数据之类，业务那边的技术团队非常独立，业务对自己技术团队影响更大。
+
+美团业务的强势度远远超过饿了么，技术要影响业务团队需求比较难，因为如果要做改造，就要有很多技术资源（时间、人员、保障等）投入，一定会影响业务交付，业务不干的。他们业务团队的技术负责人直接汇报给业务老大。
+
+但饿了么不是这样，我进去之后，先是所有的技术都在我这边，但后来发现这样有问题，这个模式不太好，我就跟汪渊商量，把业务的技术跟业务的产品都实线汇报给他，但业务的技术虚线汇报给我。虽然是虚线，但因为汪渊和团队的信任，这个虚线还是比较强的。所以倒不是说罗道锋他搞不定，是业务根本不鸟你，我们这边就比他要好一点，我几乎能完全掌控，即使业务技术团队只是虚线。
+
+                        
+                        
+                            

专栏/超级访谈：对话张雪峰/15兴趣与个人认知.md

@@ -0,0 +1,107 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            15 兴趣与个人认知
+                            极客时间：听说你特别喜欢数学。
+
+张雪峰：我最爱的除了家人，就是数学、历史这两块，数学是我从小的兴趣，所以花的时间多一点，我主要在B站上数学系的专业网课。
+
+也有人问我是不是现在闲了才看，我说不是的，我一直在看。以前只是周末有时间，要系统学习数学还是有点挑战，因为周末后再上5天班，基本就接不上了，所以那时候看科普的多一些、专业体系化的少一些，坚持了很多年。虽然很多人也不相信，但这个确实是我从小的爱好。
+
+还有一个催化剂就是，我刚上高一就拿了当年全国高中数学联赛省一（上海），但离那年（上海）省队有点距离，遗憾没能进冬令营。当时还自我安慰，如果在其他奥数一般的省，大概率可以进冬令营（笑）。但即使这样，也是我们学校那年重磅新闻（张雪峰高中是当年浦东唯一市重点，但不以数学见长）。当然了，我师兄更强，他高一省一、高二冬令营、高三国家队且是那年 IMO （国际数学奥林匹克竞赛）满分金牌。师兄是我当年最好榜样，也激励我对数学的持续热爱，直至今天。
+
+极客时间：数学能给你带来什么？
+
+张雪峰：数学带给我精神上持久享受，自然美感觉很棒。很多同学都有能带给他持续精神快乐的事物，对我来说，主要就是数学。或者更精确一点，是基础数学（纯数学）。
+
+极客时间：是享受而不是那些枯燥的运算。
+
+张雪峰：对，而且数学是自洽的，只要在这条路上，跑出来就是对的。数学和物理不一样，物理很多是人想出来的理论。杨振宁那套理论，已经是目前为止理论物理的天花板，几十年都看不到激动人心的突破，你看今年诺贝尔物理学奖，能知道个大概。物理更多是一个没法自洽的学科，它需要靠实验、工艺，靠现有的工业技术去证明，但数学几乎是完全自洽的。
+
+极客时间：在工作之后还能持续钻研数学的人，好像很少，你会考虑到数学在工作中能不能用得着这样的问题吗？
+
+张雪峰：我就是Enjoy这个学习过程而已，其实我刚从阿里离开的时候，很多投资人找我，问我有没有兴趣创业或投资，我说我的兴趣主要在数学、历史。但对企业来说，企业更Enjoy结果，数学尤其基础数学，这个东西不太能直接产生商业价值。
+
+极客时间：在平时的工作中，你会用数学的思维跟大家去讲道理吗？
+
+张雪峰：会，而且经常用，或者更多是用逻辑的思维。大家不要被一些所谓的计算机原则（典型如：低耦合、单一原则等）迷惑，数学原则才是宇宙终极原则。
+
+就像我前面讲过的，什么时候该内聚、什么时候该解耦，你不要被表面迷惑。举个例子：当大于等于两个调用方（消费者），都会去调用一段逻辑的时候，就需要考虑抽象为 Function/Service/API，就这么简单。我经常会跟大家这样类比，不要把简单的业务问题人为地引向技术复杂化。如果是创新或试错业务，更要 Speed 第一，活下来后，才有时间谈 Architecture，最后才有机会上 Scale。之前提过的物流团队极致异步架构、部分团队微服务过度等，都是教训。还有，以上观点可能并不适用真正技术驱动业务的公司或业务，比如：Google、IaaS/PaaS、无人车等。
+
+数学是解释抽象最好的方式（物理也高度依赖抽象，但还需实验与观察），有人说为什么要学数学？买菜只要学小学数学不就行了？那不叫数学，那叫算术。开始有未知数这个概念才算摸到数学一点边。解方程有未知数，这就是一个抽象，然后再往上还有更高级的抽象，比如大学的抽象代数，可以把很多物理现象抽象出来。
+
+我还想说一点，跟抽象对应的还有一个词叫“想象”，但想象这个东西很多时候是天赋，不是说你想要想象就能有，想象是可遇不可求的，抽象是你需要去锻炼的能力，这是可以锻炼出来的，不是靠天赋。举个例子，你可以感觉一下：线性代数教会了我们如何抽象看待所有线性方程组，多次螺旋上升的抽象过程后，天下再无不可解线性方程组；但同样是数学，初等（平面/立体）几何中各种精巧的辅助线（有些可以靠刷题或训练，但大部分难题还是靠想象或天赋），却是很多同学数学学习过程中的绝对梦魇。要么一分钟解出，要么只能看答案后叹为观止。
+
+极客时间：你刚刚说了两个思维，数学思维和逻辑思维，它们有什么区别吗？
+
+张雪峰：都属于“形式科学”，另两类是大家更熟悉的自然科学、社会科学。要说数学思维比逻辑思维更深一层的，除了抽象、缜密，还要有广阔想象、大胆创新。创新指创立全新数学工具甚至数学分支，用于解决当前体系无法解决的难题（详见“哥德尔不完备定理”）。如果只让我推荐一本关于数学想象的科普书，那一定是《思考的乐趣》。
+
+极客时间：之前我们有聊到产研团队按领域划分的事情，饿了么之前的团队划分比较粗糙嘛，就是分C端和B端，C端就是APP和网站，B端就包括商户服务还有物流，你进去之后第一件事是做拆分，这里面其实就要用到逻辑思维。
+
+张雪峰：饿了么原来就是个单体，所有的业务逻辑就是一个东西、一个源代码库，C端、B端、D端（Delivery，物流）全在一起，牵一发动全身，也就是说你在部署的时候，每个服务器都要布一坨这个东西，一是影响性能，二是发布很麻烦。只要有同学发布，即使跟你无关，你也要发布一遍，所有的机器都要扫一遍。我们做技术的就要拆解，肯定要至少再分一级。
+
+拆分与否，我们当时就遵循一个原则：只要一个人有变化，一堆人要随着你动，或者叫“牵一发动大部分”的时候，这一定是有问题的。其实这也是逻辑原则或数学原则。所以我跟他们说，不要扯什么领域驱动、微服务了，就用这个原则。这个原则确实最容易讲清楚，但实践的时候要多次试、反复试。
+
+单体是一个极端，微服务或单一原则是另一个极端。饿了么从来没有真正提过微服务，从来没有过，我不去用这个概念。我们就是从业务的合理性去拆分。对领域驱动呢，我当时也是持观望态度，不能说保留态度，我觉得领域驱动是一个模棱两可的东西（顶尖DDD牛人或在大规模超复杂体系下成功实践过的同仁勿喷，毕竟让绝大部分技术同学吃透DDD，无论ROI还是效率都很低），就跟架构一样，所以我希望回归朴素，就是从逻辑的角度，或者数学角度，给大家解释。所以当时我们也不做领域，我把以前的经验带过来，开始有一些中台的萌芽，比如说把交易系统、营销系统拆出来，把用户系统拆出来等等。
+
+从逻辑上讲，当你十次里面有八次“牵一发要动大部分”的时候，你就没必要去拆，你就让它耦合（内聚）在那，哪怕最后合出来一个巨大的东西，那证明这个业务就是这样的，没办法。你要么抱怨很倒霉进入这个业务领域，要么你就自己想办法克服。当然还有一个办法就是你通过技术去改革这个业务，那意味着这个业务甚至整个行业的游戏规则都要变，在短时间内几乎不可能。之前也讲过，对绝大部分公司的技术团队来说，妄图通过技术驱动业务，还是省省吧。
+
+极客时间：刚说到中台的萌芽，饿了么建立中台大概是一个什么样节奏呢？
+
+张雪峰：最早是整合交易系统，后来整合营销系统，搞营销系统就附带着把会员系统也搞在一起。其实说到底，也不叫营销，叫权益。所谓的发券、会员体系，其实归结为一点就叫权益。这一点国内有两家做得非常好，一个是携程，一个是淘宝的 88 VIP。
+
+我们搞中台不是从0到1，应该说是从1到10，因为我们本来就有这部分（交易系统等），只是散在各个团队，后来就是交给石佳宁他们团队去整合，整合的过程当然也比较痛苦。
+
+架构调整的时候，我们把C端、B端各个跟交易有关的团队交给中台去整合，这就涉及人员调配，有些Leader就不愿意交人嘛，就是“你动我的模块我可以忍受，你动我人坚决不干，我转模块不转人”。这种情况在阿里是严禁的，阿里一定是转模块必须转人，阿里做得比较到位，这就是成熟组织的表现。
+
+我们以前这个团队，即使我强压也不行，大家就拒不交人，他说这个员工你让他过去，他要离职的。到后来磨了几次之后，大家也慢慢立下规矩：如果交出一个完整模块，必须人跟着模块走，去另一个团队，如果不愿意就离职。
+
+所以一开始石佳宁其实拿到的是全部模块和光杆团队，相当于活儿给他，但要他自己找人，虽然我给了他很多权限。所以，石佳宁是很不容易的，他几乎只靠自己原来的班底，然后还要去熟悉C端、B端、D端（Delivery，物流）业务，把代码拿过来之后再拼起来。
+
+他们从最难的交易系统开始做，搞定了之后，发现交易系统还不是最难的，最难的是营销系统。营销是千变万化的，运营介入最多的就是营销，因为营销有很多玩法，搞各种优惠活动。营销不好抽象，非常考验程序员对业务的抽象能力。
+
+运营他们不管的，提了一堆需求，说给我实现这个、实现那个，技术人员就要去抽象。最后我们的营销系统变态到什么程度？那个界面刚开始做出来，只有运营看得懂，一堆Check Box，而且还不能点错（有些可以点错，后台有告警，但太多告警，人也会麻痹）。我们曾经因为运营点错按钮出过事故，最后责任归到运营，但人家也很委屈，吐槽技术做得太烂，说你们这个产品简直不能忍受，搞这么复杂，勾错就出问题。但技术人员就是一根筋，他说我已经全给你抽象出来了，所有的功能你只要点勾就能实现。所以营销系统是很难做的。
+
+极客时间：可以谈谈你对中台的理解吗？
+
+张雪峰：中台就是业务（商业）驱动的。我以大家更能理解的阿里来说，阿里后来做中台，其实真正的核心动力还是商业驱动。比如我在优酷注册了一个会员有一个优惠券，为什么不能在双十一的时候去淘宝买货？我在淘宝有积分，为什么不能在阿里其他平台用？所以淘宝得到一个终极结果就是 88 VIP，就是会员体系，这才是中台的原动力，还是要从商业价值来看。把这些权益放在一起之后，用户就有更大几率留在你的平台。
+
+饿了么后来也搞会员系统，我们早期就是发营销券（外卖券），做营销券打通，开始还没有把它抽象成权益打通，后来有了会员之后，才想到要做权益，因为围绕会员的、跟消费有关的都叫权益，这个就更有价值了，包括把混合券这些东西都包容进去。
+
+所以中台不是个业务，但它有业务的味道。
+
+极客时间：接下来我们聊几个大的话题，你的人生理想或者说人生追求是什么？
+
+张雪峰：除了家人，我还真没想过这个问题，如果抽象来说就是人和事两方面。
+
+我先从人这个层面说，我希望我把一些不同的人，培养到超越我期望至少超越我的一个程度。就像我之前说，做CTO的最大成就感来自团队的成长。超出期望就意味着，他不是我原来可以掌控的，我会在这过程中和同学一起成长，对底下的同学来说，他感觉是我把他培养出来，但同时我也学习到很多。所谓相辅相成、相互成就，大概就是这个意思。
+
+我有这样的理想，后来跟很多人也说过，我非常不想做CTO，我就想去挖掘高潜的人，我感觉我可能更擅长做这个角色。当然我现在在做这种“冒牌中介”，也是希望去把一个合适的人匹配到合适的岗位，其实做这种红娘是很有成就感的，不亚于去介绍两个同学或两个陌生人，最后成为夫妻这种成就感。
+
+从事这个层面，我只能说是追求美，是精神上的一种美，不是视觉或感官上的美。什么叫精神上的美，或者精神上的成就感呢？对我来说排第一位的就是数学，可能直到离开这个世界，我也会一直追求下去，既是兴趣，也是挑战。
+
+极客时间：你有比较喜欢的行业吗？
+
+张雪峰：我对一个行业很有热情，我过去大概20多年的经历，有一半时间是在这个行业里，就是教育。
+
+育人是一件很有意思也很有意义的事，有时候我自己看一些科普文章，很多很深的数学问题，有人就能把它用很简单的方式讲出来，让别人豁然开朗，我觉得很厉害。可能我对这样的事比较有热情，而技术只是我第二或第三兴趣，有时也是没办法，或者说你得先有饭吃，必须养家糊口。
+
+极客时间：你有偶像吗？
+
+张雪峰：历史上我有特别佩服的两个人，一个是商鞅，一个是李靖。但他们算不上偶像，我好像过了需要偶像的年纪，如果非说一个，应该是我第一家公司的老板。他20多年前的理念，甚至到今天依然前沿、足够前瞻，20多年前，他就已经在做标准化的事，是通过公司的产品尝试标准化，不止是停留在标准化理论上。
+
+我的感受相当于什么呢？当时进这家公司，从编程来说，我算是小学毕业了，但是突然间一个中科院院士在那边给我辅导，就是这种感觉，而且他又非常平易近人，可以让我有学习的机会。一般的中科院院士即使再虚怀若谷，他也不可能跟一个小学毕业生去谈科学的。我至今还是一直认为，他对我的技术或技术观方面影响最大，但商业方面没有，因为他商业做得不太成功。
+
+极客时间：你有没有自己坚持的人生信条或者是座右铭？
+
+张雪峰：我总结六个字：活到老，学到老，再加上对精神美的追求吧。我希望一直到我生命结束，我都尝试去影响其他人对“活到老，学到老”的追求。从我的家人开始，这一年我已经引起我太太对历史的兴趣，开始买书看，还有我女儿，她以前也从来不看，现在算是有一些起步。
+
+当然我能影响更多人更好，但是影响更多人也比较难，我也不想去做博客、去B站开个号，甚至写书等等，我不太想做这样的事。可能我觉得也很难影响到别人，一本书里面的内容，很难放之四海皆准，就像我们今天的访谈，即使把这些观点尽可能的普适化，让别人真正理解也是很难的。
+
+我更想个性化地去做一些力所能及的事，去挖掘出一些不同的东西。“活到老，学到老”的另一个说法就是，持续去学一些不同的东西（Difference）。
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/01小厂项目：做程序员不难，难的是做职业程序员.md

@@ -0,0 +1,237 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            01 小厂项目：做程序员不难，难的是做职业程序员
+                            
+你好，我是叶芊。-
+　-
+欢迎来到访谈现场，今天我们会从毕玄进阿里之前的经历聊起，他的这段经历少有人知道，却格外有趣，又格外现实。-
+　-
+2002年从江西南昌大学毕业的他，在大学因为兴趣，从学盲打，到玩组机，到写网站，早已练成了网站编程老手，但毕竟是生物学毕业，第一份工作他是怎么找的？能顺利转成程序员吗？-
+　-
+我们正式开始对谈。
+
+
+　
+
+极客时间：你大学生物系毕业之后就想转去做程序员，虽然背景是非计算机专业的，但大学做了很多商业性的项目，这种条件你也还是非专业吗？你第一份工作怎么找的？
+
+毕玄：是非专业。我当时不想在江西呆，觉得还是应该去大城市，就想去北上广深，第一选择是北京。但北京真的太难了。
+
+极客时间：那会在北京你是怎么选择目标企业的？
+
+毕玄：那个时候哪能选择目标企业（笑）。我大学的背景又不好，尽管南昌大学号称是211，但可能就江西有名声，在外面大家基本都没听过，北京就更不用说了。另外我学的还是生物系，要找的还是计算机系的工作，哇这个太难了。
+
+我在北京逛了一圈，那个时候还必须去人才市场。我去人才市场逛了一圈就知道北京肯定没戏，所以觉得我还是不要在北京了，北京太难了，以后可以去，现在就算了。
+
+后来我去了深圳，因为我有个朋友认识某家公司的人，就推荐了一下，我被推过去之后，别人觉得我不是学计算机的，但是我从大二开始就在外面的公司写商业的网站，有很多经历，这是拿出来很硬的，就跟现在找工作一样，至少我的项目比较实际，所以他们觉得也可以，就说那你来试试吧。
+
+这算是彻底转变了，因为你想你的第一份工作是计算机，就进圈子了，后面其实没有人会关注你大学学的什么，已经无所谓了，也不会因为大学不好就刷掉你，不会，他更关注你的工作经历。但第一份确实挺难的我觉得，尤其跨专业，非常难。
+
+
+
+极客时间：深圳那个公司是什么业务？你是做什么的？
+
+毕玄：那个时候有一家做手机的上市公司叫科健，我们是科健旗下专门做政府软件的子公司，都属于科健集团，背景说起来很挺好的，但这家公司知道的人很少。
+
+为什么说跨专业难，我招进去的时候其实都不是程序员，我是负责做实施的，公司做了一套软件卖给了政府以后，要有人去现场安装、教人用啊各种，现在叫交付，以前叫实施。
+
+我刚进去的时候他们其实让我干的这个，原因是我真的写不了程序。虽然我在大学确实写过一些网站，但是完全不一样，第一次进那家公司，到现在我都印象非常深刻。
+
+当时项目组正在做佛山市政府的OA系统，去了一看，所有的人电脑上打开的，因为他们不是写ASP的，他们做OA都用的VB（Visual Basic），VB我完全不懂，当时我就看到一帮人打开VB在那“哇哇哇”写代码，写得可熟练了，我真的惊呆了，就很仰慕。
+
+但我觉得这活我是真干不了。因为开始我也不想做实施，我想写代码，后来我去看了一眼之后觉得确实自己干不了这个（笑），我还是先做实施。然后就被派去佛山的一些政府部门帮他们装上OA，解答一些问题，陪他们聊天。当时政府部门虽然能讲普通话，但习惯讲粤语，我跟他们混了半年，听粤语的水平就是那个时候训练出来的，虽然我不能说，听没有什么问题。
+
+　
+
+
+
+　
+
+极客时间：总搞实施，个人发展应该比较受限，那你后来是怎么开始写程序的？
+
+毕玄：半年后，当时我直属的老板，他决定给全部新人一次机会，我记得，印象很深刻。
+
+当时我们有些人对写程序很感兴趣，加上又都跟项目组的人住一起，所以做实施的时候，我们会跟人家学一下VB怎么用，怎么写程序、搭系统等等。
+
+然后经理他可能也觉得需要更多人写程序，因为说白了实施的人很容易找，但写程序的人有点难，尤其写软件相对还是有要求。后来半年左右，他想看看能不能从这批做实施的新人里面，挑几个人来写代码，就给我们出了一道题。那道题是要在他们现有的程序里改一个功能，限定所有人三天改完，并且交付出来。
+
+刚好在第三天的时候，我终于找到了要改哪里，其实就一行，那个需求只用改一行代码，关键它可能有上万行代码，你要从这上万行代码里找出到底要改哪一行，但因为不是他们（写的人），我们不懂，也不大熟。反正刚好在第三天，我找到了然后改好了这行代码，我的角色从此就变了，变成了一个专职程序员了。
+
+极客时间：这个直属老板你觉得，当时对你是什么样的影响？
+
+毕玄：这就是机会问题，说白了没有这个机会，你其实走不进这个行当的。非专业的人最大的挑战，一你的学校不够好，二你是非专业的，真的想进入一个行当，你的门槛会比别人高很多。
+
+如果你是个名校生，还是学计算机的，程序员的工作随便找，还肯定是大公司，这就像很多人说的我工作很多年以后，才有资格跟你一起坐在那喝咖啡，但人一起步就是那样，我觉得这是事实，必须得承认。所以我跟他说还好当年有了这一次机会，让我正式开始做这个行当。
+
+
+
+
+
+　
+
+极客时间：这次通过了考验，你也抓住了机会，成专职程序员之后有比较顺利吗？慢慢通过做项目提升自己的技术水平？
+
+毕玄：那没有。
+
+我的主职变成写代码之后，就跟着他们做佛山的项目，项目做完一年以后就调回深圳，开始做整个深圳市的电子公文交换系统。
+
+比如说我这个政府要和另外一个政府部门联合办公，就要发红头文件，之前是纸质的。但广东的电子化非常早，深圳是2003年开始建电子公文交换系统，各家就可以直接发电子公文，我们公司就承担了深圳市的那个项目。但那个项目我参与的很少。
+
+极客时间：为什么没有参与进去？应该是个大项目。
+
+毕玄：因为那个项目主力成员是写Java的，就这原因。
+
+但我的背景对吧，以前学校做网站用的ASP，到佛山之后跟着项目学会了VB、Delphi，因为我们有些是用Delphi写的，有些用VB写的，这两个我慢慢也比较熟。然后深圳比较缺人嘛，把我调回深圳，一看Java，我又傻眼了，我说这啥，好不容易VB和Delphi我已经用得特别熟了，因为真的也特别好用，然后一切到Java，我就觉得这玩意简直烂到极致。
+
+因为Java那个时候的IDE，说实话跟VB、Delphi比，即使到今天这俩还是神器，当时Java，哇塞连IDE都找不到，Eclipse是后来的事情，最早Java我们都用记事本写的，哇那效率简直低到离谱，后来才有了一个简单的IDE去学Java。
+
+所以我就从那个时候开始学习Java，学这玩意到底该怎么弄，因为我确实外行不懂，所以在深圳那个项目里我就没进入多少，公司有非常主力的Java成员去负责，然后那个项目做成了。其实深圳这段经历让我很难忘。
+
+极客时间：难忘的是什么，因为工作需求自己紧张学习新语言？还是说当时自己不太做的上事，心态上可能比较挫败？
+
+毕玄：因为不像我在佛山，说实话佛山一年我已经混的很熟了，而且已经是那个团队里比较主力的程序员，像公司在顺德这些地方的项目就是我自己去搞的，我一个人，面对需求方，直接改代码，然后交付给他们，可以全部自己干完，所以在佛山过得挺爽的。
+
+结果调回深圳后，直接就啥也干不了，全部是别人干，你是一个啥也不懂的人，所以挺不爽的，那段时间本来我想走的，找另外的。但是发现也很难，那个时候我找到华为。
+
+极客时间：你去面试了？结果怎么样？
+
+毕玄：那肯定，那个时候深圳最好的是华为，互联网公司像腾讯我们都看不上的，因为我们这种人在大学多数是做过网站的，会觉得不就做一个网站，能有多难，我几天就可以做一个，腾讯这样的公司，在我们这都是玩烂了的，互联网公司？我们觉得那都是做不了软件的人才去的公司，做政府软件还是要求挺高的。后来我们都后悔了。
+
+极客时间：没有早进去（笑）。
+
+毕玄：因为我以前的公司就在现在腾讯深圳南山区总部的隔壁，那个时候，园区是没有互联网公司的，全部都是软件企业，至少在圈子里，大家会觉得软件企业的程序员肯定比互联网公司的程序员更厉害。
+
+当然这是因为我们这群做软件的人，根本不懂互联网的人面临了什么问题，后来我们了解了之后，才知道，哇还是你们牛。
+
+　
+
+
+
+　
+
+毕玄：当时本来我想如果能离开，就去深圳最好的公司华为，我去华为面试了一下，然后面试不上，那我还是继续在现在公司待着。
+
+而且我在那家公司刚好有了一个新机会，因为深圳项目快收尾，我第一任老板他也从佛山回来了，他那个时候已经是软件部的副经理，回来以后被任命了一个新项目，中山市的网上审批系统，非常类似现在浙江做的“最多跑一次”。
+
+极客时间：材料网上审批这么早，那个时候是几几年？
+
+毕玄：所以说广东非常领先，那个时候是2004年，当时中山市就决定做。你要去政府办的所有事情，可以在网站上一次提交所有材料，提交完了就到政府内部去流转，流转完了之后，你最后去现场把所有资料拿走就可以了，几乎也只用跑一次。
+
+当时我们公司中标了中山的这个项目，我之前的老板就跟我说，要么你别做深圳项目了，跟我做中山项目去。
+
+极客时间：你有做过什么考虑吗？还是说很果断就直接过去了？
+
+毕玄：当然，我们这么熟的人，我当然跟他走（笑）。于是我就跟他去了中山，这个项目在当时是非常大的纯软件项目，我们中标的金额应该在1000多万。
+
+但去的时候我们就3个人。
+
+很多同事当时是不大想去的，因为我们老是做项目要到处跑，很漂泊，虽然我号称在深圳工作，但你看我在深圳的时间非常短，第一年根本没在深圳，我都在佛山。
+
+所以就我们3个人，要去做一个1000多万的纯软件项目，而且我们都不知道是个什么东西，什么都不懂，去了以后就发现有很多问题。比如说我们当时面对了中山市的市长、市委书记和秘书长，这是秘书长亲自牵头的一个重要项目，但当时正逢换届，做的挺不容易的。但也不是坏事，所以后来我们也明白政府项目真的太难做了。
+
+极客时间：这个项目可以具体聊聊吗，你当时负责什么？
+
+毕玄：这个项目金额大，公司给的支持还是很够的，允许招更多的人，但因为我们仨去的最早是绝对主力。我老板本来就负责这种项目很多年了，人脉很广，所以他主要对外搞定各方，另外一个同事负责写更上面一点的东西，我负责写网上审批系统整个大的基础，那个时候我已经偏向写框架了，很类似现在很多公司做的低代码框架。
+
+因为我们做的东西是这样，中山市的项目要上线1000多个流程，如果你写代码上线，那做10年也做不完对不对，所以你必须要让别人很容易直接把这个流程配出来，这就需要在下面抽象一个东西。
+
+极客时间：需求这么急，项目又很大，当时你们有考虑买个商用的自己改吗？
+
+毕玄：最早我们当然也准备买商用的，后来觉得不大好用，所以决定自己写一套流程引擎、表单引擎等等所有东西，我就写这个。那个时候我还有一段神奇的闭关体验。
+
+因为我们判断这套流程引擎和表单引擎对这个项目至关重要，决定了这个项目到底能不能在2、3年收尾掉，而不是说要很多程序员去堆，最好的方案是一套框架加上大量的实施工程师、配置工程师。所以我们发现了这是核心。
+
+然后我的老板就问我，多久能搞完？我说我一个人就行了，给我半个月。于是我就享有了整个项目组最高的待遇，我就圈了一间会议室，那个会议室就我一个人，闭关写了半个月代码，半个月后有了一套雏形，后来很多人就基于这个东西配流程上去。
+
+极客时间：就你自己一个人半个月搞定了？
+
+毕玄：对呀，我就在那里面，吃喝什么的都有人送过来，全无打扰的环境，过的很爽（笑），写完了之后，反正也基本能用，他们后来就边用边改，撑住了系统后来的整个实施过程。
+
+　
+
+
+
+　
+
+极客时间：但是当时写的时候，没有遇到什么难点吗？毕竟这应该是你第一次做这么大的项目。
+
+毕玄：其实还好，因为工程说实话没那么难，很多只是抽象的问题，写计算机程序其实是个逻辑过程。
+
+极客时间：写代码是逻辑过程我大概能明白，怎么理解是工程？是抽象问题？
+
+毕玄：就是数学。我现在特别理解写程序的人有两项技能特别重要。一是英语，这没办法，因为你看的大部分资料是英文，你写的代码也是英文；第二个是数学，写程序其实就是一个数学过程。
+
+数学是一个什么过程呢？是我有一个问题要求解。程序也一样，程序是我有个问题，然后求解，所以程序的整个代码就是解问题，就像以前数学题我们写第一个字“解”之后的所有部分，那就是个逻辑。
+
+对数学特别好的人来说，数学题可能会变，但他能从变化中找到一个规律，抽象成一个函数，变成一个公式，核心问题是举一反三。为什么高斯特别牛，从1加到100，首先他找到了一个规律解答了1加到100等于多少，但在这个基础上，他还能把1加到N变成一个公式等于（N+1）*N/2。这就叫抽象能力，他可以把一个问题抽象成一个公式，然后这个公式可以运用在所有场景里。
+
+其实写程序就是这个过程。不好的程序员是有一个问题就解了，解完了以后问题稍微变一下，这个代码就得重写；但写的好的是看到这个问题，我可以做一个抽象，之后不管上面怎么变，我可能只需要换换参数之类的，但代码是不用改的，就能完成所有需求。
+
+极客时间：所以像你当时在那个项目里负责写框架，就会更需要抽象一些？
+
+毕玄：对，我们写底层框架的说白了就是这个过程，底层框架为什么相对更难，是因为它对抽象能力的要求比上层代码的要求更高，上层是我面对一个需求，做到就可以。
+
+所以做一个程序员不难，做一个职业程序员其实很难。程序员就是我有一个需求，然后翻译成代码而已嘛，这个东西小朋友确实能干，所以现在少儿编程很多。我就跟我家小朋友说你们学的那些东西，只能是写着玩，想拿这个当饭碗，少儿编程学100年也不会变成职业程序员，因为职业程序员学的东西，在那个阶段你是根本体会不了的。
+
+但是如果你数学很好，你写代码的逻辑性、抽象能力会非常好，其实后面自然能领会，因为你想，写代码我们就是写一个方法，方法是什么？方法不就是个函数，一个典型的数学函数。
+
+当然也不一定就能成为，毕竟你后面还有很多挑战，但至少有一个基础在，离成为职业程序员更近。但数学不好的人，说实话我们觉得是不合适做程序员这一行的，因为你逻辑性不够，抽象能力不够，就导致你写的代码经常要改。
+
+
+
+
+
+　
+
+极客时间：最开始我们聊的时候提到非科班的程序员和科班程序员的区别，我记得你之前还特地写过一篇文章讲业余程序员和专业程序员的区别。这两种区别，是一样的吗？
+
+毕玄：不是，我是非专业的系，但我应该是职业的，就像现在大家都觉得好像是个人都能写程序，这我不否认，每个人都能写程序没错，多数人只是把这个问题翻译成了代码而已。
+
+但是这段代码要变成能稳定执行的商业性的代码，这是职业程序员才能干的。说实话这我完全不相信任何人都能干，所以我最讨厌说什么人人都是程序员（笑），太鄙视这个行当的专业度了，其实每个行业都有专业度，有人觉得到最后AI可以替代所有，但那个真正的专业度，我觉得还是有一定难度替代的。
+
+所以做中山市项目那段时间写偏基础的东西，对我自己还是有锻炼的，没有碰到太大的困难，可能因为我的数学比较好。一直以来我只有两门好，一门是英语，一门是数学，语文和物理、化学都非常糟糕。
+
+极客时间：根据你的理论，那你可能注定走上程序员这条路（笑），有一点好奇，你数学好，为什么物理没有那么好？
+
+毕玄：我也很好奇。大家都认为数学好，物理一定好。我后来想因为物理是解释现实世界规律的，数学不是，数学其实是个工具，所以很多物理学家同时是数学学家。但物理我就很难理解，我的物理和化学都在及格线上徘徊，但数学就是在满分线上徘徊。
+
+不过说实话我认为跟老师也有很大关系，因为后来我们在阿里听过一次北大前校长讲物理学，他是物理系出身的，讲完之后大家都觉得哇物理太有意思了，我说以前自己要是遇到这样的老师，物理至少应该不会那么差。
+
+其实生物也一样的，最近我在看很多生物的东西，就觉得很有意思，一些非常知名的教授讲生物研究是要去解决人类的什么什么问题，你就会觉得，哇如果我真的能研究出这种问题，那在人类历史上，跟计算机系的人根本不是一个档次的。我就跟我家小朋友说，如果我以前看到的是这些，我应该不会去做计算机这行。
+
+因为说实话我现在会觉得计算机只是个工程，你可以认为计算机是个工具，但对人类不会有根本性的变化。但生物、物理，可能会给人类带来非常巨大的改变，而且它有很多问题要解决，但计算机说实话对那些人类问题没有任何帮助，可能是个好工具可以帮我来让那些问题解决掉，但它只是个工具而已。
+
+　
+
+水友讨论区
+
+今天的对谈就暂时结束了，针对毕玄大学毕业之后找工作的经历，我们林林总总聊了很多，不知道有没有引发你对他之后经历的兴趣。
+
+虽然是生物系毕业，但大学四年他基本都在玩计算机做了很多商业项目，也能算一名准程序员了，即使这样，找第一份工作也非常难，哪怕找到了，想正式成为程序员也是抓住了稍纵即逝的机会。想想大佬起步居然也这么难，突然有点安慰了:)
+
+“啥也干不了”的艰难开局后，让我印象最深刻的是聊编程、计算机和职业程序员的部分，毕玄说职业程序员是需要专业度的，但计算机只是个工程，是个工具。
+
+不知道你最感兴趣的是什么，这里我列了几个话题，欢迎自由讨论：
+
+
+“非专业的人最大的挑战，一学校不够好，二你是非专业的，真的想进入一个行当，门槛会比别人难很多，是个机会问题”，你的第一份工作是怎么找的？是非专业吗？
+有人说人人都是程序员，毕玄说写计算机程序是个逻辑抽象过程，但职业程序员是需要专业度的，你怎么理解“职业程序员”？
+毕玄现在觉得计算机只是个工程，是个工具，关于计算机在人类社会的作用，你的想法是什么呢？
+
+
+如果你有其他更有发言欲的话题，欢迎交流，期待和你在留言区碰面。
+
+下一讲我们接着毕玄在小厂做项目的波折经历聊，下讲见。
+
+拓展阅读
+
+1. 毕玄很早就开始写博客了，考古挖到了他工作三年写的复盘：程序人生(工作三年的回想)
+
+2. 如果你对业余程序员和职业程序员的不同感兴趣，可以看毕玄后来写的一篇文章：从小朋友的一道数学题聊聊职业程序员
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/02小厂创业：做出一个产品，卖给所有人.md

@@ -0,0 +1,200 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            02 小厂创业：做出一个产品，卖给所有人
+                            
+你好，我是叶芊。-
+　-
+上一讲我们聊到毕玄艰难的非专业找工作经历，这个大学不怎么样的生物系青年是怎么毕业后成为一名程序员的，今天接着他在小厂做政府项目的经历聊。-
+　-
+因为剧情太过跌宕，忍不住简单剧透一点点，在好不容易接了个千万级的大项目之后，他又想跳槽了，这次连简历都没写居然跳槽成功，之后又开始了一段神奇的创业之旅，但创业一年后，他却表示：太没意思了，不如回去打工算了。-
+　-
+到底发生了什么？我们开始今天的对谈。
+
+
+　
+
+极客时间：做了佛山、顺德这些地方熟悉了VB，但是深圳项目又要从0开始学Java，所以你本来想走，结果峰回路转有了做中山1000万大项目的机会，做完了之后呢？
+
+毕玄：中山做了两年多我还是想走了，因为我一直漂泊，很不爽。
+
+我们公司的项目就是这样，除非做深圳项目就在深圳，其他地方的一定在外面。当时，我们公司在广东的电子政府领域比较有话语权，因为做了深圳、佛山、中山，除了广州，这基本就是广东经济最好的三大城市。所以公司当时更希望继续拓展广东的其他城市，那就意味着我八成继续在外面。
+
+极客时间：你说的“拓展其他的”会有点重复做的意思吗？这样你的个人发展可能不是太好？
+
+毕玄：会。一我觉得不想做项目，因为做项目太漂泊，二我觉得项目这个东西太不规模化了，我们每做一个项目都是重来。
+
+尽管我们当时也希望，像很多软件公司，比如做了A政府，做完以后沉淀成一个产品卖给B，但是说实话，我当年做过以后就知道这条路是走不通的，绝对不可能，今天也是这样。
+
+因为说白了是不能复用，A做了这个东西取得了一定的成绩，B想的并不是拷贝这套，他一定会改，想要在这个基础上创造一个新的东西，否则的话，请问你的创新在哪？所以现在做项目讲这个故事的人，只能说应该还是做得太少。
+
+极客时间：这是做政府的，那做公司的是不是也一样？都是ToB的大思路？
+
+毕玄：办公这种系统有点不同，但如果是涉及它业务的也差不多。你卖给我A公司一个业务经营的软件，如果跟卖给B一样，请问我跟B怎么竞争？我要你做的就是不一样。所以最后，你就变成了一个大型交付公司。我觉得这是突破不了的，不可能改变。
+
+中国做很大的像东软，你想东软难道没想过这个问题，肯定想过对不对，大家谁也不傻，他们难道想一个项目一个项目做吗？肯定不想的，他们当年肯定想过怎么把这个东西变成一个产品，或者说至少变成相对标准化的，去另外一个可以很快交付掉的。
+
+这类公司中国有非常多，我相信他们一定探索过。因为他有这么多项目，理论上大家会觉得以前为什么做不成，是因为项目太少所以抽象不够，如果有100个项目我一定能抽象出一个东西。
+
+极客时间：但是这个说法，大家好像都在这么说，也都这么认为。
+
+毕玄：这基本不成立的，后来最多做到OA这玩意可以标准化的卖，但实施难度也很大。前期大家讲故事的时候说，要不断做项目，最后可以有个抽象，但后面很难。
+
+所以你看做这些软件企业有很多家，从我们当年到今天，这些公司很多都还存在，但说实话没有多少是发展非常好的，东软比较大，然后泛微，就这几家，东软那么多的人，你说他有收入吗，他当然有，但你说他有多赚钱、体量能做到多大，就没有。就他其实没有成为非常好的行业。
+
+极客时间：这是结合你当年经历的总结，我们看现在这种类型的创业，你觉得还是这样吗？
+
+毕玄：现在尤其很多技术人，出来创业先做政府项目，一开始这一点他们是完全没有搞明白的。我们做的多了就知道一上来，一定要先摸清楚项目需求到底是什么情况？为什么要做这个项目？
+
+除了诉求，你还得搞清楚各方的利益关系。因为一般项目时间很长，你还有周期，但凡不是一两个月能交付完的，跨年了甚至半年以上，还会有人员变动，那你就相当于有另外一个人再过来接你这事，他俩如果目标不一致，重新来一遍，需求重新提。
+
+极客时间：噢就是要想清楚做产品的出发点。所以像现在很多人会纠结，为什么我的产品这么好，但客户不用，是不是没太想清楚的一种表现？
+
+毕玄：这就是诉求没搞清楚，因为客户的诉求可能跟你想的完全不一样，你是去解决他的问题，如果没有搞明白他的诉求，你瞎搞，客户反而很烦。
+
+以前听别人聊，说有些客户的需求会非常奇怪，他对项目的效果没有任何诉求，目的其实是想跟你联合做个PR，他认为给你了比如1000万只是买个广告费而已，反正投放一个广告也要这么多钱。我们听到这个逻辑都震惊了。
+
+但是你如果再想一步就很明白了，因为有些企业的行业竞争非常激烈，他们会觉得如果能跟你合作一把，可以塑造成我是科技典范、先进企业，我上下游的其他企业就会这么认为，然后我的订单量就增加了。所以他们其实根本不在乎这个项目，因为他获得的订单远比这个数量要大很多。
+
+那如果你是这个项目的PM，是不是很爽？因为客户对项目没有要求，所以你正常流程做，验收完就收到了钱。难道不应该感谢这种客户？难道你们一定要做一个多牛的东西？
+
+所以乔布斯以前才说绝对不要做to B，他只要做ToC，ToC反正就是自己说的算。
+
+
+
+
+
+　
+
+极客时间：好，我们聊回你的经历，当时你决定不做项目了，去面试了什么新公司新岗位吗？
+
+毕玄：当时我最想找的是做产品，不是做产品经理，我想做一个写产品代码的。所以我的诉求就是找一家能做产品的公司，但是没有面试，也很神奇。
+
+当时大概是2004年我想换工作，开始找机会，我2003年就写Blog了，那个时候写博客最火，我以前写了挺多的，正好有一个人看了，然后那个人是上海一家公司的软件部经理，他看了之后觉得要不聊聊，就这样我去了上海。
+
+那家是上海电力集团下属的一家生产企业，理论上是专门给电力做软件的，但它有点特殊，它除了给电力做，还希望拓展到非电力的行业，所以希望做一个产品能够覆盖其他的行业，叫协同办公，类似钉钉。办公这个行当其实很多年了，因为办公是刚需。
+
+极客时间：在办公领域，当年和现在只是解决方案不一样？
+
+毕玄：只是解决方案在不断地进化，越来越好用了，因为以前都是PC，现在是移动。所以那家公司决定做这个产品，就说让我去，并且让我做整个产品的架构师，那我觉得这个位置太好了，是我梦寐以求的，又满足了做产品，还能做架构师，太好了，所以我就去了。
+
+极客时间：那很好啊，你没面试，进去还是核心岗。
+
+毕玄：但第一天简直就是悲剧（笑），我现在都记得。
+
+因为去了之后，我周五报道的，报道完老板跟我讲，要我下周一出这个产品的架构设计思路，我想架构设计思路？啥玩意？我都不知道这个东西是什么，然后我就开始瞎编。
+
+压力很大，但反正最后也给了一个什么东西乱七八糟的。然后我就开始负责这个系统的架构，以及核心的代码，都是Java的，从中山项目以后我就已经走向Java体系。
+
+但产品真的太难做了，一家公司能下定决心做一个产品是非常难的。他们投入一段时候之后，觉得做了半年好像也没有出啥东西，所以他们反思还是做项目比较好，于是我们又接了一个项目，东风汽车的项目，在武汉，不在上海，我又带着几个人在东风驻场做了接近一年，唉我实在是抗不住了。
+
+极客时间：所以你本来想摆脱做项目，才选择到新公司做产品，结果阴差阳错又回来了（笑）。
+
+毕玄：尽管我变成了整个项目的负责人，面对的关系更综合一点，角色比以前更高，但做项目这种经历我真的太受不了了。
+
+极客时间：那你当时又准备走了？
+
+毕玄：当时也很巧，我做了半年多，我的第一任老板决定出来创业。
+
+极客时间：就是那个给你机会的经理吗？
+
+毕玄：对，他就跟我说一起创业吧，我就去了。
+
+我本来就想换工作，东风项目快收尾了，我觉得也没什么意思，因为这样下去看来公司也不大可能继续做产品，可以理解，公司尽管有电力的背景，但还是会考核一年的营收，毕竟也是投入嘛。但如果你要专注投一个产品，真的要投挺久的，2年多很正常，投几十个人算下来钱也不少。很多公司就是这样，现在也一样，很多真正有壁垒的产品是它投入了很多年，外面的人想抄就要投很多的钱，这是壁垒。
+
+所以，我就觉得既然他想创业，我们关系又很好，正好我干的也不爽，干脆就回去跟他创业去了。
+
+
+
+
+
+　
+
+极客时间：当时你们创业是想做什么？
+
+毕玄：创业我们的目标就是继续做政府软件，因为我们之前做佛山、中山、深圳，我老板其实一直是最重要的负责人，跟政府各方都很熟，所以我们觉得应该可以做吧。这就是第一次创业的人，啥也不懂。
+
+开始我们有3个人，我写代码，他各种都干，另外还有一个专门做商务的人，本来我们认为佛山、中山应该有些机会，但后来发现政府招标对资质有很多要求，但创业公司最难的就是资质，短时间也很难有。我们仨搞了将近一年，觉得太难了。
+
+后来就去找了以前的朋友，他们是中国做公安非常大的一家，就给了我们一些项目，都很神奇。
+
+极客时间：公安的项目？那是做什么的？
+
+毕玄：当时刚好是中国做二代证系统，我们负责做公安系统，就是把一代证的信息转移到二代证上的中间系统。这个可搞笑了，出了很多问题。
+
+因为我们的代码能力尽管是有，但说实话，还是不大行的（笑）。基本一出问题，我就得在公安局呆着，因为我们公司也没几个人，就是我飞到各处，现场改代码处理各种问题，所以那段时间我更惨了，全国跑，在内蒙古最冷的时候我去做了呼和浩特的系统，然后甘肃、兰州也待了几个月，还有云南、昆明，我全部去的这些地方。
+
+就那一年，我们做了一些相对偏远地区的公安系统。最终我们3个人都觉得，这玩意没戏，做不成，因为那个时候我们的梦想其实也是，做出一个产品，卖给所有人。
+
+所以现在我跟所有在行业软件这个行当（这和通用性的软件例如CRM等不一样）创业的人都说，我真的不相信能成，除非软件有很革命性的进步，如果没有，你们做的方法跟我们当年其实没有太大区别，那为什么当年做不成，你们现在就能做成了呢。
+
+别幻想这些故事， 不过因为这个故事是所有人的梦想，换一帮人，这个梦想还是可以讲下去的，但你没有真正做过这个行当的话，是不知道它背后很多东西的，你会觉得它好像是成立的。
+
+　
+
+
+
+　
+
+极客时间：这么看感觉做不下去了，后来呢？你们就散伙了？
+
+毕玄：我们3个人做了接近一年，觉得这活肯定干不下去，也不可能做大，那有啥意思，不如大家回去打工算了。就在我们在要回去打工的时候，突然接到了一个神奇的机会，那个机会就是互联网公司，500彩票网。
+
+500网当时是中国最大的彩票网站，准备冲刺上市，他们觉得原来的那套系统技术不大行，就希望有一个全新的团队，来写一套全新的系统彻底替换掉原来的那套。
+
+他们的负责人刚好跟我老板比较熟，就说要不你们也来，当时我们创业反正也觉得干不下去了，我们觉得行，可以干，就去了。
+
+就因为干这个项目，我才懂了互联网非常有技术含量。因为那个时候团队里有些是腾讯出来的，就跟我们讲为什么腾讯QQ是难做的，并不是大家想象得那么没有技术含量，讲当规模上来的以后，你会碰到什么问题，讲腾讯是怎么解决的，我们听完觉得那确实挺牛的。
+
+所以我就去了，但这个项目因为主要是腾讯的人，而腾讯的主力语言是C。
+
+极客时间：啊第一份工作被迫学VB，后来到Java，现在你又要学C了。
+
+毕玄：我又悲剧了，但因为我Java已经做了那多年，不想再换语言了，那在这个团队里我到底能干啥呢？所以后来我就干了一个非常神奇的角色，做了这个项目里的DBA。
+
+极客时间：但之前你也遇到相似情况了，VB和Java都学了，为什么当时就不想再学C了？
+
+毕玄：一是我不想换语言，另外这个团队里C背景的人也够多了，都是腾讯出身的，技能非常好，他们相当职业，而且这伙人见过当时中国最大规模的网站，我临时学一下能跟他们比？这个难度有点大。加上项目时间要求非常短，可能只有几个月，所以要的是大家尽量快。
+
+我想了下，没有别的能干，就数据库没人干，好吧那我就干数据库，因为完全不懂，那个时候就开始每天学数据库。
+
+极客时间：那之后呢？
+
+毕玄：做了几个月，本来这家公司上市的流程都快走完了，在美国IPO几乎没有什么问题了，但在就要上市的前一个月，中国颁布了一个规定不允许在互联网上买彩票。
+
+说实话我们本来打算冲刺上市，获得一笔钱然后走的，没准备在这家公司待太久。这样一来觉得上市没有希望了，大部分人当然就撤了，我也在其中。
+
+我走的原因很简单，一我也不想做数据库，这显然不是我的长远方向，说实话本来就是一个短期的活，第二我肯定想回到做Java的工作，然后也开始觉得互联网是一个很好、很有技术含量的公司，所以我希望找一个做Java的互联网公司。这就是2007年了，我年底加入的淘宝。
+
+-
+　
+
+水友讨论区
+
+到这里对谈就暂时结束了，今天我们主要聊的是毕玄正式成为程序员之后做项目的故事，不知道有没有引发你的思考。
+
+从毕玄写千万项目的底层框架开始，我就隐约有了大佬崛起的感觉，毕竟他说写程序其实没什么难的，就是工程，是抽象问题，果然老做项目的他觉得成长不好，开始找新工作了。虽然找新工作非常不顺利（又有一丝安慰;)），但是从曲折的经历中，他也深刻地明白了做项目和做产品的区别。
+
+不知道你对今天的对谈最感兴趣的是什么，我列了几个话题：
+
+
+有人说客户需求是个哲学问题，而不是与客户沟通的问题，不是客户提到的就是需求。你做过ToG/ToB的项目交付吗，感受如何？
+对于“抽象成产品，卖给所有人”的梦想，你的看法是什么？你觉得未来会向什么方向发展呢？
+毕玄的语言使用经历是：大学做网站的ASP -> 做项目学的VB/Delphi -> 第一眼觉得简直烂到极致Java -> 彩票网站被迫用的C，不同的语言，你在工作中学习/使用过哪些呢？换语言的体验如何呢？
+
+
+欢迎在留言区参与讨论一起交流。下一讲我们会接着毕玄进淘宝的经历聊，下一讲见。
+
+拓展阅读
+
+如果对毕玄当年能吸引到offer的博客感兴趣，你可以看看这几篇：-
+1. 项目杂感-
+2. 做家中间件厂商到底有多难-
+3. 产品规划-
+4. 质量和快速决定了软件架构
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/03淘宝HSF：能让淘宝出重大故障的就那批人.md

@@ -0,0 +1,228 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            03 淘宝HSF：能让淘宝出重大故障的就那批人
+                            
+你好，我是叶芊。-
+　-
+上一讲我们聊到毕玄加入互联网公司的经历，为冲刺上市的彩票网站写新系统，因为自己不会C语言，也比不过腾讯那拨人，迫不得己成为了一名DBA。但因为突然的规定上市无望，他也走了。-
+　-
+后面发生的事情，说实话我只能说“很神奇”。-
+　-
+就他准备找新工作的时候，在没写简历没主动面试的情况下，居然又有一根橄榄枝神奇地伸了过来，然后在一场很神奇的面试后，他进了淘宝，结果第一个项目就神奇地差点把淘宝搞挂了……-
+　-
+到底发生了什么？我们马上开聊。
+
+
+　-
+极客时间：2007年底你就去阿里了，当时你是怎么进去的？
+
+毕玄：也是博客，我到上海工作是因为写博客，换到阿里很大原因也是这个，当时我在网上写了OSGi那份文档，OpenDoc，那个时候可流行开放性的文档。
+
+极客时间：这篇文档影响力很大，你写了多久？
+
+毕玄：一点点积累的，前前后后可能有半年多。
+
+极客时间：半年？这么久？
+
+毕玄：对，就写了那篇东西，写了之后技术圈的关注确实比较大，最早我们觉得产品化的基础可能是基于OSGi做，因为Eclipse那个时候已经是Java的垄断IDE了，而Eclipse的底层是OSGi。
+
+当时Eclipse把OSGi把插件化的整个体系讲得，你如果听一下思想都会觉得太完美了，而且有Eclipse展示，相当于有了落地，还不光是一个概念，所以大家都觉得哇这是革命性的，基于这个抽象有可能做成产品，只是后来论证了一些东西，不是这样。所以当时OSGi在国内的关注度非常大，加上又没有文章，我写了第一个，很多人可能就因为这个知道了我。
+
+极客时间：那个思想是什么，可以具体讲讲吗？
+
+毕玄：从业务上讲，以前做整套系统想做成产品，产品化的核心思路是复用，但你不大可能把所有东西都做了，那最好的方式肯定是插件，A、B如果有不同的需求，我做个插件，插在原来的上面做扩展就好了。
+
+而Eclipse是完全基于插件体系的，在里面如果一个功能没有，你装一个插件就有了，然后插件还可以扩展，你想跟别人的不一样，改一下代码就可以，还只用改部分。我们觉得这是一个完美的思路，把很复杂的东西抽象掉，做插件、做扩展。
+
+其实到今天为止，所有的扩展型系统仍然是这么构建的。只不过OSGi可能太复杂了，但它的思想其实被用在了所有系统上，现在想产品化的公司，面对复杂系统，还是插件、扩展点的套路。
+
+我们当时觉得这个方向是有可能的，Eclipse也给我们展现了一个完美实践，所以我们说应该研究下来，然后我也比较感兴趣，也觉得这个东西应该就是灵丹妙药。中国又没资料，就开始自己研究了，加上我确实比较喜欢写文章，写上瘾了，就有了那篇非常长的文章。
+
+极客时间：所以你写出影响力之后，你是怎么去淘宝的？像以前一样有人看到你的文档被联系过去的？
+
+毕玄：写完之后，有个人叫曹晓钢，他做了一个网站叫满江红，以前很多人会用，包括我们搞Java那帮人，那篇文档放在了网站上，可能中国学习OSGi的人都看过了，所以我跟晓钢就非常熟了。
+
+当时比较凑巧，刚好我准备找工作的时候，晓钢就问我要不要考虑下淘宝。因为那个时候他的一个朋友刚刚加入淘宝，那个朋友就是菲青。因为菲青中国朋友比较少，很幸运晓钢就是他的其中一个，菲青刚刚加入淘宝在招人，也找不到别人，就问晓刚能不能推荐几个，就这样我被推荐给了淘宝。
+
+然后我就到杭州面试，说实话那个时候我们不觉得淘宝名声很大，虽然有一定名声，因为它刚刚打败eBay，听肯定都听过，但觉得好像也没啥。出名的是老马。因为马云在前一年上了创业的节目，在那个节目里风格非常犀利，圈粉无数，那我觉得很好啊，就到淘宝面试。
+
+
+
+
+
+　
+
+极客时间：你被推荐过去之后，然后就顺利进去了？
+
+毕玄：没有，进淘宝很狗血的。当时晓钢还问我面的咋样，我说我觉得不咋样。
+
+面我的第一个是黄裳，淘宝比较老的一个工程师现在蘑菇街的联合创始人，黄裳第一轮，菲青第二轮，第三轮是马钰。
+
+那个时候黄裳问我很多问题，我都不知道，菲青问我，我也很多都不知道，马钰问的时候我就更懵，因为他是带搜索团队的，问很多算法，算法我不懂，他让我做道题，也没做出来。后来我就说你们到底是怎么让我通过面试的（笑）。
+
+但是最后很神奇的是，等面试结束的时候，马钰居然问我要不要考虑一下加入他的团队，我都震惊了，我是来面菲青的团队，然后马钰说你要不要来我们这。当时我想，啊？我题都没做出来，你们为什么让我加入？这什么团队。所以很搞笑的。
+
+最后当时淘宝整个软件技术部的老大空闻面我，空闻说你前一年不是在做数据库吗，现在为什么面的是Java工程师？空闻简直震惊了。反正很神奇的，我就这么加入了淘宝。
+
+极客时间：所以你到底是怎么通过面试的？时机原因吗？
+
+毕玄：后来我们一帮当时加入的人都开玩笑说，当时的淘宝估计是你只要投简历，就会招你，根本就没什么面试流程，就是个形式。这可能真的就是运气，但很多公司都这样。
+
+因为07年愿意来淘宝的人非常少，包括我们去校招，淘宝绝对是阿里集团里最后一个被选择的。到后来我们才有了很多的要求，淘宝是09年经历的大规模发展，整个架构做了演进，就会有很多要求，比如希望你做过大型系统。
+
+这像我们07年进来的这批人就废了，应该是进不了淘宝的，会被碾压，做过大型系统？没见过，并发量上十万的都没见过，更不用说其他非常非常多的要求了。阿里后来招的人，实践经验简直能亮瞎眼，本科就已经非常厉害了，不用说像硕士、博士，但这是阿里很正常。
+
+极客时间：除了你说的运气，应该也有你写OSGi文章的原因吧？
+
+毕玄：应该有，后来我跟黄裳他们都说，你们招我，八成是因为OSGi吧。因为他们面试问的很多跟淘宝当时用的整个技术体系相关，淘宝当时又要做服务化，他们觉得这些你是不懂，OSGi你懂啊。但是问那个，他们就不知道我回答的怎么样，因为说实话我答的对还是不对，他们也不知道，只是觉得你有一个点是非常专业的，所以也可以（招进来）。但肯定不是因为我对淘宝多了解。
+
+
+
+
+
+　
+
+极客时间：好，我们接着你进淘宝之后的经历聊，你是一进去淘宝就开始做HSF了？
+
+毕玄：对，因为OSGi是一个偏服务化的东西，淘宝当年最重要的策略就是做服务化的架构演进，只有我是有这个背景的，所以进来之后，我就很自然地负责做这个东西。
+
+但问题是，其实我也没做过，而且我们那帮人都没做过大规模的系统。我当时面临的第一个问题是技术选型，但我们根本不懂大型系统的技术选型挑战是非常大的。
+
+以前我做政府，说实话随便选好了，更多的是看功能，但互联网更多的是看性能，功能对互联网来讲一点都不重要，越少越好，但性能是核心。所以我进来做的第一个技术选型后面就是一个巨大问题。
+
+极客时间：当时你做的选型可以多讲下吗？
+
+毕玄：我们做HSF，第一个要选的是通信框架，淘宝最早是WebLogic，菲青进来以后再换成了Jboss，我进来之后，因为菲青用JBoss，就决定也选Jboss的通信框架，把Jboss的老版本升级成新版本，顺带把通信也基于Jboss来做。这就是我们以前的选型（笑），所以后来我们会不断地教育新人，不要瞎来，有非常严格的规定。但以前互联网可能大家都不懂。
+
+所以我们就选了，做了第一个版本上线，这是我面对的第一个大规模系统，日均访问量是200万。我以前做的10万不到，一下直接200万。那个时候所有人都会告诉你做一个网站，访问量10万、100万、1000万、1个亿、10个亿是不一样的，但没有人告诉你到底哪里不一样。
+
+因为当时中国没有圈子，就很窄。但国外就有很多，QCon以前在国外的大会有很多互联网公司讲他们的技术，非常适合中国做互联网的那帮人，这点必须说QCon是真的打开了中国交流的圈子，所以我们以前都是看国外的东西。
+
+极客时间：所以你上线就出问题了？
+
+毕玄：没有，我当时上线以后很正常，所以突然间我就觉得，完全感受不到你们吹嘘的到底有多难嘛，你们是不是在忽悠我啊。我就信心爆棚了，决定不要上这种不那么重要的系统，因为当时上的系统是给阿里的客服小二用的，出问题相对还好。
+
+我们就决定直接上阿里最重要的系统，交易系统。当时交易系统日均访问量大概是1个亿左右，相当于从200万到1个亿的跨越。结果上线的当天就出问题了。
+
+当时发布的时候，大家都去千岛湖Outing了，就留下我和黄裳俩人，因为大家觉得应该也不会有什么问题，所以你们俩就留下发布吧，那个时候发系统都是半夜，不是白天。我们俩半夜开始发系统，发完了以后回去睡觉了。
+
+一大早我就接到监控的电话，说整个淘宝现在很诡异，也说不出来哪里诡异，好像比平时慢一点，就是这个描述。
+
+
+
+
+
+　
+
+极客时间：接到监控的电话，你们就赶紧去公司查问题了？查了多久？
+
+毕玄：当年不像现在处理故障有一套专业的流程，而且要求响应非常非常快。当时我们觉得都无所谓，我和黄裳就去公司查，从早上查到晚上。所以后来我们在内部分享的时候都说，按我们当年处理故障的状态，都被阿里开除无数次了（笑），因为现在你必须立刻回滚掉，但当时我们俩觉得，不要回滚，先让我们查一下问题再说。
+
+关键是我们从早上查到晚上都没查出问题在哪，但晚上的时候已经非常严重了，淘宝已经快打不开了，支付宝那边已经快挂了。我们俩也抗不住了，猜想八成就是HSF，虽然业务代码也改了，但换的核心就是这里，所以我们就把HSF回滚掉了，换成了原来的方式，一切恢复了。
+
+然后我就悲剧了，这不用说压力就非常大了，那个时候我入职4个月，刚过试用期。
+
+极客时间：有没有转正？
+
+毕玄：已经转正了，但也压力很大，毕竟出了很严重的问题，而且就我一个人做这个系统。我就下来开始仔细回顾整个系统，慢慢查，但因为已经回滚了，也不纠结啥了。后来我们就发现了只是一行代码。
+
+极客时间：查了多久？
+
+毕玄：可能查了一两个星期。
+
+极客时间：两星期？不会很焦虑吗？
+
+毕玄：心态都还好，我可能觉得不管怎么样，反正先查出问题，其他的后面再说，而且不至于说我出了这个故障就被开掉了，这菲青肯定还会给我机会。但下一次压力可能就真的很大了，因为下一次说实话是不能出问题的，再出问题我觉得我自己也不好意思呆下去了（笑）。
+
+极客时间：刚转正就出现了这么大的故障，可能你属于比较冷静的。
+
+毕玄：我觉得看得开就好了。
+
+因为我们后来发现有些人会想太多，比如做一件事情，就想着我要通过这个事获得什么，那八成是会做的乱七八糟，出了故障就想会不会被处罚，对晋升、奖金有没有影响，老想这些，那肯定没法做了。如果你什么都不想，先搞定它，剩下的事情等搞定再想也不迟。关键是，你现在想也没有用，你想不会改变任何东西，先安心干好你的活不就好了。
+
+极客时间：面对重大事件，你的这种心态，你觉得和之前自己做项目的各种坎坷经历有关吗？
+
+毕玄：那我可能高中就是，高中考大学不就是重大挫折嘛。因为我们高中是全省能排前几的，尤其我那个班，可以认为是超级重点班，只要能进那个班，基本都能上重点大学。当时我们每届都有奥赛金牌之类的，上一届还有省状元。
+
+但我觉得这是个接受问题，因为我中考进我们班的时候是正数第8，但高中第一次考试，我就已经二十几名了。
+
+极客时间：二十几名之后你是选择接受，不是说“不行，我得整回去”？
+
+毕玄：你当然会努力，但努力一两次之后，你就会发现你得接受。因为我的几个好朋友，成绩非常非常好，但他们一点都不努力的，根本不读书，上课听一下，下课从来都在玩游戏，但考试每次都能考前几名。所以我说这是接受，很多人可能接受不了，觉得好像很怎么样。
+
+就像我的好朋友，他高中一直考第一名，高考的时候全校都在看他有没有机会得省状元，最后他稍微有点失常，但应该是全省前十，就去清华了，后来我去清华找他聊天，他就说他终于懂了，我们高中的时候是多么痛苦。
+
+极客时间：他也像你们高中一样，发现自己学不过别人？
+
+毕玄：对，因为他进清华，第一次考试就是班上最后10名，他一看别人成绩这么好，就变得非常努力，每天早上7点就去图书馆学习，一直学到晚上。但即使这样，他一直都在后20名。
+
+极客时间：可能他也需要适当接受。
+
+毕玄：对，他就接受了，因为他看到前几名也是那样，跟他高中一样，也不怎么读书（笑）。
+
+所以是心态，以前我们总说“但行好事，莫问前程”，当然面对重大问题的时候另外有抗压性的问题。
+
+但抗压很难训练，我总不能给你造个故障，这对公司影响太大了，到底怎么训练面对这种重大问题，一个人的反应是什么。当然阿里后来有很多故障演练，你也不知道那个故障是真的还是假的，会故意出现一些，真假混合，就看你的反应。我们确实会发现不是所有人都适合的。
+
+极客时间：面对故障，不是所有人都适合抗压，那有没有人因为这个离开了？
+
+毕玄：也会有的，但不多。因为说实话，真正要面对这种压力的人。
+
+极客时间：人都是很少？如果能让你去做这么大的系统，他一定是经过检验的。
+
+毕玄：对就是少，你说对了。真的让淘宝整个网站出严重故障的人，说实话也就那批人。
+
+那批人，很多都能接受是因为觉得就算出故障然后被开掉了，那又怎么样，我还是能找到一个工作，而且不会差，就会觉得无所谓了，有啥好纠结的。说实话，很多人担心还是因为不够自信，害怕如果被开掉，可能就怎么样了。但是不害怕的都是那批，大不了就开掉，这就是最差的结果，这我都能接受，那我还怕什么。
+
+极客时间：这是当年，有点好奇现在呢，能让淘宝出重大故障的人？
+
+毕玄：现在就不好说了。因为公司大了，出故障的影响面不一样，你现在出故障可能是真的会受到一些处罚。但以前没有处罚，以前尽管号称有，但也不会多严重，因为我们也确实被处罚过，包括绩效等等会受影响，反正大家看得开。
+
+　
+
+水友讨论区
+
+今天我们主要聊的是毕玄进淘宝，以及做第一段专业领域的系统设计的故事，不知道有没有引发你的一点思考。
+
+之前在知乎搜毕玄，在一个不那么正经的帖下面找到了他相当正经的一段发言：
+
+
+
+当时我还将信将疑，但在今天了解了他07年的淘宝面试经历后，疑虑打消了，可能当年那波公司都有一段这样尴尬的时间，之后应该也会有。
+
+进淘宝之后，毕玄做的HSF上第一个系统大获成功，于是这名热血青年信心满满上了1亿日均访问量的交易系统，结果被故障狠狠教训了一把，差点达成进厂就被裁的成就，但他表示稳住心态，先安心干好活，没有什么好纠结的。
+
+不知道你对今天的对谈最感兴趣的是什么，照例是自由讨论环节：
+
+
+OSGi的插件化思路，你是怎么理解的？在哪些系统里感受到这种设计思路吗？
+工作中你出现过严重的故障吗？影响如何？当时自己怎么处理的呢？
+
+
+欢迎留言参与讨论，留言区是匿名的，所以欢迎自爆，也欢迎马赛克人名爆别人的料，毕竟独乐乐不如众乐乐，让大家一起围观引以为戒:)
+
+我们下一讲会继续毕玄在淘宝的经历聊，下一讲见。
+
+拓展阅读
+
+1. 这是一扇传送门，关于毕玄做HSF的复盘，我们后面单独有一讲，聊一聊他对这次故障的深刻反思，以及之后怎么才能顺利做成事的参考经验。
+
+2. 如果你对阿里的技术演进感兴趣，可以看《淘宝技术这十年》。
+
+3. 满江红网站还在，首页也能看到OSGi那篇文章（毕玄网名Bluedavy），但链接失效了，如果感兴趣可以看看毕玄博客里的这篇：说说OSGi。
+
+4. 如果你对用OSGi做服务框架的思路感兴趣，当年毕玄也写了一系列思考：-
+服务框架的要素的blog-
+基于OSGi实现服务框架的分析-
+基于OSGi实现分布式服务框架历程(一)-
+基于OSGi实现分布式服务框架历程(二)-
+基于OSGi实现分布式服务框架历程(三)-
+基于OSGi实现分布式服务框架历程(四)-
+分析分布式服务框架
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/04淘宝消防队：真正最优秀的程序员不应该是英雄.md

@@ -0,0 +1,243 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            04 淘宝消防队：真正最优秀的程序员不应该是英雄
+                            
+你好，我是叶芊。-
+　-
+上一讲我们简单聊到毕玄进淘宝后做HSF的经历，以前他做网站访问量10万不到，上来一下到200万，再直接跳到1亿，他的心情也从“信心爆棚”直接跳到了“上线爆雷”，毕竟刚转正就让公司出了严重故障，他表示压力山大，但是自己心态还行。-
+　-
+今天我们接着他的经历聊，当时在淘宝他还有一段相当有趣的经历——淘宝消防队，在这里他锻炼了自己的解决问题能力，也结识了阿里的知名大神多隆，但是在采访中他却说这种机会对公司来说其实是个恶性循环。-
+　-
+为什么他会有这个看法？淘宝消防队的经历对他来说究竟意味着什么？我们开始今天的对谈。
+
+
+　-
+极客时间：看你的经历，HSF做完你就去淘宝消防队了？
+
+毕玄：不是，淘宝消防队是一个插曲，就它是个民间组织。因为09年淘宝经常出问题，出问题以后，当时的最大问题是没有人去解决。
+
+以前我们就一个系统，如果出了问题，大家都会去看看是不是跟自己相关，但是我们在09年以后有100多个系统，大家都觉得如果出问题了，肯定不是我的问题，所以就没有人查问题，导致那段时间很糟糕，客服感觉明明有很多用户在投诉，但技术这边反馈很慢，都不大去解决，就很混乱。
+
+后来我们运维线有一个人很不爽，就拉了个群，这个群的名字叫“消防队”，群里拉了一些我们觉得愿意去解决问题的人，后来只要出问题，这个群里的人就会去解决。
+
+极客时间：噢没有组织上的约束，那这些人确实没有责任必须要处理问题。
+
+毕玄：没有。只是这帮人觉得问题老没有人解不好，当然还有一个原因是这帮人比较喜欢解问题，有这个爱好，以前你想解也没有问题，现在你一进这个群简直了，只要想解，问题一直有。然后我们就有一帮人进了这个消防队。
+
+这个群以前有个默认规则是：不允许M线的人进来。阿里是P线、M线，M偏管理。后来有一个副总裁不小心被拉进来，但很快就被踢出去了，然后他就问为什么要把我踢掉？我们说因为解决故障的时候不需要你，解决故障的时候需要P线的人，而不是M线的人。他也很无语。
+
+极客时间：副总都能直接踢吗？这个操作挺勇的。
+
+毕玄：这个群慢慢大家都知道了，因为大家发现只要反馈给这个群，问题是会被解决的，就形成了效应，加上又没有官方组织。可能半年多的时候，不知道为什么群被更多的高层知道了，因为我们最早说一不允许M线，二要低调，最好没有人知道这个群的存在，尤其高层。因为我们要操作生产环境，理论上肯定是有点违规性质的，权限会过大，所以我们也不想太高调。
+
+但被知道了以后，在淘宝年会上，公司临时决定要给这个虚拟组织颁奖，好像是总裁特别奖之类的。我们就突然被通知你们的群得了个奖，颁的时候我们印象都很深刻，因为是临时的来不及订奖品，就从现场，当时在黄龙体育中心，找了一个灭火器，颁给了这个消防队，然后颁奖的时候还跟我们说，等会儿下来，记得把这个灭火器还回去。
+
+极客时间：所以是给了虚拟团队一个虚拟奖。
+
+毕玄：就是给一个荣誉，我们都笑死了。
+
+后来公司知道了，觉得不能靠虚拟组织，这个事情还得官方化，所以成立了官方的消防群，那就不一样了，进群的责任有一条就是处理问题。但尽管有官方了，我们有少数几个人被列在了某个名单里，那个名单里的人被特批拥有全部权限。但这是因为我们过去做了很多事情。
+
+反正当时对我来讲挺好的，借机学了很多怎么解决问题，而且多隆也在里面，我跟多隆就是那样熟起来的。以前我只知道他很神，但不知道哪里神，但在消防队我充分感觉到了为什么，很多问题很难被解决，但多隆基本都能解决，而且几乎横跨所有领域，这太夸张了。
+
+极客时间：这种解问题也是非常锻炼人的机会吧？因为我看你写自己的技术成长过程，总会提到在淘宝消防队的这段。
+
+毕玄：因为这是个训练。我后来跟多隆总结出来就是“卖油翁，唯手熟尔”，你越被喂就越熟练，越熟练就越被喂，就像打游戏一样。但这是个什么循环？你可以认为是个良性，也是恶性。
+
+对个人就是良性循环，比如说你解多了，公司很多人都觉得你解问题不错，所以大家有问题都找你，你被训练得越来越惊艳。但恶性就是公司其他人没有机会了，因为处理问题通常都是很紧急的，大家一定会第一时间想，谁能最快解决，就找谁。
+
+　
+
+
+
+　
+
+极客时间：你淘宝消防队的这段经历，是不是给自己赢得了很多信任，也为你后面的很多机会做了铺垫？因为像你这种刚开始出于兴趣去做，后来被问题训练得越来越强，这种人，在技术的人眼里应该会相当受认可吧。
+
+毕玄：通常来讲技术圈里，每家公司大家觉得最牛的那个人，多数是解决问题能力特别强的，公司的很多危机时刻，是他出来把问题解了，鲁肃当年就是这种。很神奇，阿里有多隆，Google有Jeff Dean，百度据说也有个这样的，腾讯也有，好像每家公司都会有一个神一样的存在，大家觉得没有什么问题是他解不了的。
+
+后来我们说还有另外一种，但这种不显眼。因为解决问题就很像英雄，出了问题然后你出面把它解决掉，另一种人是他写的东西几乎没有出过问题，就不会被暴露出来，但这种人其实是真正要挖出来的。因为前面的不挖他就在那了，不需要挖。
+
+极客时间：英雄和这种不出问题的，是不同的能力水平吗？
+
+毕玄：程序员的技能水平我一直说可以分成三段。
+
+第一段是你的基本技能，比如做这个业务要写相应的代码，那这个代码相关的东西你得非常了解，包括背后的细节。我们觉得这是程序员的第一关，迈向职业化。
+
+说实话这跟公司中、小、大没有任何关系，关键看你对自己的要求，公司可能不会明文说你要怎样，尤其是中小公司，因为说实话，每家公司不对个人成长负任何责任，反正你没成长，公司大不了换一个人。但你自己应该有追求，用到的所有东西都应该去了解它背后是怎么回事，否则现实讲很容易被淘汰的。
+
+极客时间：这里想多聊两句，你有没有什么衡量自己了解程度的具体方法？你是怎么做的？
+
+毕玄：写文章和分享。我觉得分享是很大的挑战，有些东西你觉得自己很懂，真正讲两个小时，你可能就挂了。
+
+以前博士（王坚）给我们上课，讲怎么判断一件事是不是个问题，因为大家会提出一堆公司可能存在的问题，他说，你们如果能就这个问题讲一天，说明这真的是个问题，如果不能，说明这根本不是个问题。
+
+因为吐槽一个公司的问题很简单，关键是这是不是真问题，而且对高级别的人来讲，肯定也要想怎么解，如果你能讲一天，这才是公司值得重视的问题，说明解法很复杂，这就真是个问题。如果很简单，公司肯定会解的。
+
+这就像技术分享，博士会挑战我们，你们不是觉得自己很牛吗？觉得对这个很精通吗？来，给我做个分享。很多人发现上去只能讲两个小时，这其实就是你掌握的全部，我以前在内部讲JVM，最早也只能讲两个小时，后来我能讲两天。
+
+这是可以训练的。所以最重要的是先把一个东西讲厚，当然另一个技能是能不能把要讲一天的东西5分钟讲完，但首先要有讲厚的能力，不能上来就讲5分钟。
+
+博士那一堂课是我们有史以来最受教的一堂课，因为这是一个很简单的方法，但所有人都可以被衡量出来。
+
+那之后我们就懂了，后来跟很多技术线的人说，检验自己的能力有一个很简单的方法，就是分享，你讲多久能把自己讲空掉，就是你能力的极限。很多人用中文随便能讲两个小时，一换成用英文讲，10分钟就讲完了，这一看就不靠谱，这其实就是你的技能。
+
+
+
+
+
+　
+
+极客时间：好，第一段是把基础打好，程序员技能水平的第二段是什么？
+
+毕玄：第二种，在程序员世界里，通常容易被认可的就是解决问题的人，就是英雄式人物。但这确实也有一个问题，因为解决问题的能力，目前看必须靠问题训练出来，很难靠自学，除非你给自己造一些问题，但还是非常难，最好有实战的机会。
+
+极客时间：有问题出现的这种机会，是每个公司都有的吧？
+
+毕玄：对，因为每家公司都会出问题。你看好了，出现问题的时候，关键看有哪些人，跟这个事情一毛钱关系没有，他还冲上来，掺和一下，一定会有这样的人，每家公司都会有。
+
+虽然开始掺和的可能也没什么用，但他掺和多了就不一样，这个人慢慢就会得到信任，然后他的机会越来越多，就会进入良性循环。这种人会慢慢成为程序员圈里的大牛，大家都会知道他，而且大家都会特别服他，不服不行，因为你真的干不过他。
+
+就像多隆，你们不服对不对？来呀。因为我们老说阿里最神的技术人是多隆，后来阿里有些新人不认识他，内网就有人说凭什么？他做了什么？结果炸出来一堆老员工，全部出来喷上面的新员工说你们知道啥。
+
+多隆很低调，不像我们这些很喜欢在台前的人，但事实上他解决问题就是比很多人强很多，这是经过事实论证的。程序员要服人还挺难，但解决问题绝对是一个，大家正面PK，两人一起解决，他就是比你快，那你还说啥？你说你能力比他强，那不可能。
+
+
+
+
+
+　
+
+极客时间：所以第一关先把个人基础能力搞好，再当一个喜欢掺和的人用问题全面锻炼自己，那第三种呢？你前面说的不出问题的？
+
+毕玄：第三种程序员，那是真正职业里最优秀的程序员，因为他写的东西很稳定，就是我们说的鲁棒性特别好，不大会出问题，但这种反而特别难挖出来。
+
+做一个程序员写正常逻辑不难，正常逻辑就是解问题，因为人脑是串行的，串行写下去非常简单，只是从说话变成了代码而已，是个翻译过程。翻译的好坏是另外一个要求，需要你对背后机制很了解，可以做到性能很高。
+
+但是一段代码，在现在正常的环境下可以跑，同时环境稍微有点异常，如果你这个代码还能跑下去，那太牛了。这是最牛的。
+
+这多数是因为他经历过前面，见过很多问题，也解决过很多问题，他才知道噢我写代码的时候，这里要注意一下，那里要注意一下。所以很多优秀程序员的代码，正常逻辑可能很少，其他都在处理一堆你觉得不可能发生的事情。
+
+极客时间：我记得你前面讲HSF的时候提到性能是一个很重要的要求，但为什么你这里说稳定性能做到是最牛的？
+
+毕玄：对程序来讲，性能当然很重要，但其实最最重要的肯定还是鲁棒性，因为我们没有办法非常好地预判这段代码运行环境到底是什么，你现在设计的时候是这样，但过段时间环境可能就变了。
+
+所以大家说看代码绝对能看出一个人的功底，只要秀几段代码，我们很快可以判断这个人的大概水平。现在我没写很多年了，但我还是能看一眼看出差别，为什么他写那几行代码，你看起来没有意义，但出问题的时候，因为有那关键几行，他的就保住了，而你的就挂了。
+
+阿里以前出现很多Bug，比如说最简单的，用一个数据结构去缓存所有用户信息，以前写的时候，他觉得这公司用户量不可能到100万，所以那个缓存没问题，但很快量就突破了，然后缓存的内存就爆了，结果整个系统全挂了。但写得很好的，他一开始就会设一个保护，到了多少会直接自己异常掉，不会把整个系统搞挂，这就是有经验的人，这就是差别。阿里出过很多次这样的故障，都不是一两次，很多很多次。
+
+后来很多人写接口也是这样，比如说我给你一个函数输入XYZ，你随便输入，因为很多人的意识是我已经在设计文档里告诉了你X不能大于1000，但是你还是输入了超过1000，然后我挂了，他觉得那是你的责任。
+
+但事实上一个好的程序不是这样的，我不是靠文档，文档上既然这么写了，我的代码里就会控制，如果入参给超了，我一定会给你一个异常，这样整个系统不会出问题，这就是一个非常优秀的程序员。
+
+极客时间：但要做到这种程度，考虑到可能存在的各种异常，然后写处理代码，这是不是也有时间成本？
+
+毕玄：这就看追求有些时候，比如中小公司，很多人就会说这个概率很低不会出现，所以他觉得我为什么要浪费时间写这些1/10000或者1/100000的事情，但我们说这就看你想不想做一个好的程序员。
+
+
+
+
+
+　
+
+极客时间：如果我们总结一下你的这段消防队经历，你是一个喜欢解决问题的。
+
+毕玄：对，因为我喜欢做英雄式的人，我本来以为很多人应该都喜欢，后来发现不是，像多隆就不是，很神奇。但以前我跟多隆比较过，我是能看出差距的，而且这个差距是很难弥补的。
+
+极客时间：看到差距了，你和高中那会一样选择接受，也不挣扎？
+
+毕玄：因为我碰到过几类这样的程序员，我必须说他们可能天生就是应该做程序员的人。
+
+就像我解决问题是要有现场在的，比如一段代码有问题，我要能看到现在输入了什么，执行的过程中出了什么问题，然后我来排查，但像多隆这种人他是可以大概推测的。因为现场经常就没有了，对我来讲就很难，我需要再等，但多隆不是，以前跟他一起排查，我告诉他这段代码可能有问题，然后多隆拿去看，过段时间来告诉我，你试一下把参数改成什么，然后跑一下看看会不会出问题，就真的会出问题。
+
+这就比我高了一个档次。这种人是可以在自己大脑里运行代码的，像我们这种就不是。
+
+极客时间：这种能力，不能多看案例训练出来吗？
+
+毕玄：很难训练，这真的应该是天生的。我们还见过更牛的。CPU可以多线程同时运行，但人脑最大问题是单线程，我们程序员写代码又经常要写多线程的并行代码，就导致查问题特别难，因为我得在脑袋里模拟计算机的并行。当时我们碰到一个并行问题，一帮人想了很久，头都要晕过去了，但以前阿里有个女程序员她就可以在头脑里同时并行跑代码，猜出问题来。
+
+我们都承认这就是天生差距，是无法弥补的，其他的我可以靠后天不断地解决问题把技能堆上去，但碰到这种，我说我认了，那我认输了。
+
+这种人你想，写代码的质量自然会更高很多，相当于在自己的脑袋里可以先跑一遍，这太恐怖了，以前传说Jeff Dean有个笑话，如果Jeff Dean写的代码跑不过，肯定是编译器出Bug了，这简直了。
+
+有些人会觉得自己学得很累，但还是很难跟别人比，说实话，这真的是天分，所以我们会跟很多人说不要都做程序员，有些人并不适合，或者做到这个份差不多就可以了，然后就躺平多爽。不用纠结一定要成为多顶尖，这个世界上这么多程序员，最终顶尖的就那几个人，你没法跟他比，也没必要去跟他比，想成长可以理解。
+
+　
+
+
+
+　
+
+极客时间：你喜欢解问题当英雄，所以从这个角度看，你在阿里之后的很多段转岗经历，好像背后都能用喜欢解决问题的逻辑来串，你看到一个问题，然后去解决？
+
+毕玄：对，我觉得跟每个人的定位有关系。我是想过我自己的相对优势的，因为每个人的优势是不一样的。
+
+后来我对自己的判断就是，我很难成为一个非常专业性质的程序员，做非常深度的比如操作系统、语言这种，因为我也试过一段时间，我带过JVM团队，他的特质是必须在一个很小的问题上持续钻研，可能只提升了一点点，他也很愿意钻研。所以说实话，多数程序员都不适合干这个。
+
+极客时间：这种持续钻研的专业性程序员，是不是有点像搞科研？
+
+毕玄：对，你可以认为这一定程度偏科学家性质。科学家就是这样在一个很小问题上，当然影响可能很大，但看起来就是一个很小的点上，不断地突破，他觉得突破0.1都是有意义的。但我不适合做这种，真的呆不住，解决问题型的人可能都有这个毛病，够用就结束了，得靠不断解决问题升级。
+
+我更适合做宽，就是广度，因为相对来讲我对各方面都有点兴趣，都愿意去了解一下。另外我可能的优势是可以大概判断，做什么事情是对这家公司相对更有意义的。这其实是需要肯思考的。
+
+所以综合起来我可能适合的是把一个事情从0分做到80分，但我不适合从80分继续做到90甚至更高。因为说白了做到一定阶段，再往下突破会很难，我需要找别的人，但我觉得，既然最后要靠我找的那帮人，那干嘛不让他们来，我就不想干了，无力感会太强烈。当然这是个人判断。
+
+极客时间：比起更偏专业技术的钻研，你喜欢在各种新领域横跳探索，是不是更偏业务一些？
+
+毕玄：一家公司的高管，越高层级包括到副总裁以上，其实是需要这种人的，因为从80分带往90分带往更高，你可以组建更专业的团队，让他们来解决就好了，然后你专注在各方面业务层面。
+
+极客时间：啊你很清楚自己更适合做什么，但能像你这样想得这么清楚，感觉也挺难的。你有什么方法吗？
+
+毕玄：当然刚毕业的时候，你不用纠结这个问题，因为刚毕业你的长短可能不是很突出，另外你其实也不知道你的长板真正在哪里，所以刚毕业的话，你也许可以多试几个角色。但是最后你一定会发现，在某个角色上你是相对轻松，而且同时干得也不错的，一定会有这样的角色，不可能没有，每个人都会有。
+
+所以不用纠结我一定要在程序员上比他干得更好，没必要，因为你可能怎么干，都是干不过他的，这就真的不用纠结。每个人还是要想清楚自己适合的，还有你的长板。
+
+但这也不一定是好事。以前阿里就有人跟我讲，你给自己画了个框，将来你是很难突破这个框的，因为你已经限定了自己，但如果把这个框去掉，想象空间变无限，就可以什么都干，尤其在大公司。
+
+我自己的看法是，如果你很年轻，确实不要给自己画框，但你如果职业生涯有限，我觉得画个框不是坏事，因为你到中后期肯定是发挥自己的长板，短板就不用在乎了，没什么好在乎的。
+
+极客时间：尤其大公司不要画框，那小公司不一样吗？
+
+毕玄：小公司我觉得完全不一样。因为小公司难道还需要一个人帮忙吸引人才，然后他啥也不干，就指望下面干活？这个人一定会被砍掉的。但大公司不一样，大公司需要有人能凝聚一帮人干成事，因为大公司管理有各种各样的问题，所以这样的人反而适合走向更高级别，他需要接受自己不是那个真正解决问题的人，但他的优势是能凝聚一帮专业的人来解决问题，这也很牛。
+
+老马就是这样的人，马云就是我有一个想法，然后有一帮很专业的人都拜依你的想法为你拼命。我也很佩服，我觉得这是不一样的，但我很难接受。所以后来我换的每一步，都是我认为这家公司现在分比较低的一个领域，比如可能是0或者60分，我觉得我去可以做到80。所以导致我在阿里换了几个位置。但后面更被动，前面确实是主动的。
+
+极客时间：HSF做完，像你后面做的HBase、T4都是主动换的？
+
+毕玄：对，后面的HBase就是因为HSF我觉得已经很难把它带到更高了，我不知道该做什么了，再做这个Leader就很不好，因为如果Leader都不知道去哪里，其他人肯定挂，所以我觉得没有必要。
+
+　
+
+水友讨论区
+
+到这里对谈就暂时结束了，在淘宝消防队处理各种故障的过程中，毕玄的编程能力也突飞猛进，也为他之后找到自己的优劣势埋下了种子。
+
+今天对谈的重点是程序员能力三关，从基础能力过关的“职业程序员”，到解决问题高光出场的“英雄”，到写的东西不出问题的扫地僧“宗师”，每一关都能让你的编程能力实现阶梯式的提升。至于如何衡量你每个阶段的掌握程度，毕玄也给了一个简单又实用的方法——分享，看你能多久把自己讲空掉。
+
+最后是今天的自由发言环节：
+
+
+对于程序员的能力阶段，你是怎么看的呢？你有哪些好用的知识积累技巧吗？
+毕玄解读了他认为做广和做深，他更擅长做广，回顾学习/工作生涯，你有发现自己在某个角色上是相对轻松，同时干得也不错的吗？你觉得自己的优势是什么呢？
+
+
+欢迎留言交流，说不定今天就是你的小宇宙觉醒之日。
+
+下一讲我们聊毕玄在淘宝的第一段转岗经历，做完中间件HSF，他居然又跑去做数据库和容器了，下一讲见。
+
+拓展阅读
+
+如果你处在程序员的第一关，关注如何精进自己的代码基础能力，毕玄之前总结了一套方法可以参考：-
+程序员的成长路线-
+程序员的成长路线(续)-
+程序员的成长路线Remix-
+怎么提升写代码的能力-
+高质量的工程代码为什么难写-
+又是一年校招季，我是这样考察学生的
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/05HBase_T4：Leader最重要的，说白了是要赌未来.md

@@ -0,0 +1,279 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            05 HBase_T4：Leader最重要的，说白了是要赌未来
+                            
+你好，我是叶芊。-
+　-
+上一讲我们聊到毕玄的淘宝消防队经历，在这个民间组织里，他发现了自己喜欢做英雄式的人，也隐约对个人的相对优势有了一些判断，认为自己不适合做专，更适合做广，更有兴趣从公司的低分领域做起，这也是为什么之后他会在阿里各个部门间横跳转岗。-
+　-
+但转岗说起来轻松，能像他这样跨大领域，还做一个成一个的，可不多见。他到底是怎么找新方向的？又是怎么把事情做成的？-
+　-
+今天我们先揭秘他的第一段经历：从分布式的服务框架HSF，到数据库HBase，到容器化T4。
+
+
+　-
+极客时间：HSF是中间件，之后你又去做HBase，从中间件跳到数据库这个转变还挺大的。
+
+毕玄：对，我去了数据平台。但其实我一开始没有想好做什么。
+
+当时是2010年NoSQL比较火，阿里内部用什么的都有，MongoDB、Cassandra、HBase，这就又出现了淘宝消防队的问题，没有一个专业的团队维护，所以一出问题，业务就挂。我们就觉得必须成立一个专业团队专门维护一个，我刚好也没有别的事干，就决定把HBase落地。
+
+但HBase做了一年之后，对我的吸引力比较少，把这个东西做得更好的动力我确实不太强，我就觉得应该干点别的，开始想到底该干啥。还好我的老板一直挺支持我的，不管我换哪个老板，基本都觉得反正你想干啥就去干。
+
+极客时间：可能你老板觉得也管不住你（笑）？
+
+毕玄：也有可能，反正我在想该做点什么的时候，看了一本讲Web容量规划的书（《Web容量规划的艺术》），所以我跟他们说看书还是有点帮助的（笑）。
+
+那本书到现在我印象都很深刻，核心观点就是一家公司如果不在乎成本的话，迟早有一天成本会超过收入，如果你不控制好成本增速和业务增速，那一定会失速，最后你业务就不能健康发展。
+
+
+
+我觉得讲得很有道理，阿里也应该干一下这个，所以我就去干了，就是T4。这也一样，开始是个非官方组织。
+
+
+T4，2011 年启动，阿里早期基于 LXC（Linux Container） 和 Linux Kernel 定制的容器调度器，T4 的技术理念与现在云原生领域的核心技术容器一致，2017年开源了名为Pouch Container。
+
+
+极客时间：非官方，就是虚拟团队？
+
+毕玄：非常虚拟。因为我当时在带HBase也不确定要不要做，就去找了多隆，还有运维线的一个人、中间件的一个人，我们四个人聊了一下觉得挺有意思的，因为我们很清楚做的目标，也找运维拉了公司机器的利用率数据，觉得有戏。
+
+极客时间：最开始这几个人你是怎么拉的？
+
+毕玄：都熟人。后来阿里很多人想做创新觉得很难，我就讲要相信一家公司到了这样的规模，你想做的事情，肯定也会有另外的人感兴趣，就看你能不能找一帮这样的人，然后私下把这个事情做到一定的阶段。
+
+之后，你有可能做成，也有可能做不成，都很正常。但是在没有做到一定阶段前，要高层支持你很难，因为通常跨了很多团队，所以只能靠你自己。从下到上是很难，确实很难。
+
+极客时间：项目刚开始是拉的熟人，后来呢，T4怎么进展的？因为看岗位，你们四个也不是容器这方面专业的。
+
+毕玄：所以我们确实做错了很多，比如说第一版方案有很多问题，我们在第二版的时候才发现原来世界上就有类似的方案。
+
+极客时间：Linux Container？
+
+毕玄：是，我们走了大概有半年的弯路，而且那半年很悲惨，因为是弯路，有很多返工，这要不是有人支持，肯定挂了。
+
+极客时间：支持的人是谁？因为有多隆这个有影响力的大佬在？
+
+毕玄：有个运维的人。我们逼他不断返工，其实他们也很想投诉，受不了了（笑），我们不断折腾，有段时间让运维那个团队每周末连续加班，接近两个月，但我们都顶住了，正常情况下，说实话这个项目八成要黄。加上多隆也在，还是有帮助的。
+
+所以大家还是要尊重专业，每个专业其实有壁垒、有门槛的，都觉得自己能做也是有点问题的，你当然也能做，但肯定跟我们差不多，来回不断折腾。
+
+极客时间：这样折腾都没黄，是不是也有信任的因素？运维团队，包括你们项目里这几个人，相信这事能干成。
+
+毕玄：对，其实任何公司都是刷脸。
+
+为什么你能干成事？为什么大家觉得你说的可以干？是因为相信你，这个信任感只能靠时间，关键看你做了什么事情对这家公司好，都是看结果。
+
+你过往的光环，顶多让你一开始很爽，因为大家都或多或少会让你刷下脸，但过了一年就没有人记得你的过去了，都只看你这一年在公司做过什么。如果还是没干啥，大家就会开始怀疑你，而且你以前背景越好，越受怀疑。
+
+极客时间：怀疑你的能力，因为别人会对你的期待太高？
+
+毕玄：对，这是高级别的人最大的风险。像我这样的，如果去另外一家大公司，多数给的职位能比现在更高，大家对你的期待是完全不一样的，比如同样的事，我在阿里做要三年，别人就可能希望你在一年内带来很革命性的变化。
+
+但事实上这个难度是很大的，技术的思想、方法都没问题，但工程就是工程，工程落地的节奏是很难压缩的，加速肯定会有风险。
+
+极客时间：那你觉得新人应该怎么做成事呢？
+
+毕玄：很多新招来的人，都想一上来就铺天盖地做一件很大的事，真的想多了。
+
+你先从一件很小的事证明你就是比别人做得好，然后慢慢的别人对你有了信任，那你机会多了去。技术人员就是这样，有信任，并且他也相信这个事情是有价值的，其实大家是愿意用业余时间去干的。当时我们几个人全是业余时间，但到了一定阶段，大家就都能看到成果。
+
+极客时间：看你的经历，总感觉你做的项目都挺成功的，很好奇你有没有做失败的？
+
+毕玄：当然有，后来做完T4我还去拉了一个业务项目。因为我一直做基础技术，很多人就觉得基础技术没有前途，然后我就听他们忽悠，找了几个人私下攒了个业务项目，淘宝首页链接转化率的优化的一个工具。
+
+极客时间：这种工具需要报备吗？
+
+毕玄：不用，因为我们拉的是负责这条线的产品，所以产品是认可的。但上线了觉得效果不大行，看来做偏商业的业务不是我的长板，后来我觉得不擅长就不尝试了，还是继续做我自己相对擅长。
+
+
+
+
+
+　
+
+极客时间：好，我们继续聊回T4，你们虚拟团队私下搞了多久？
+
+毕玄：因为都不是我们的主业，干了可能有半年多，应该是到了2011年我们确实觉得这个事情可以干了，我就去跟当时的老板正明（章文嵩）聊了一下，决定不带HBase团队专职做T4。T4应该是最早的容器，跟百度同年开始的，但是阿里高层的支持原因，进展速度慢很多。
+
+极客时间：什么支持原因，可以多讲下吗？
+
+毕玄：因为当时阿里已经有阿里云了，理论上讲云是阿里集团战略，肯定是重点发展的，公司希望大家用云的技术，整个阿里都跑在虚拟化上，而不是你们自己又搞一套容器化。
+
+
+虚拟化，通过虚拟化技术将一台计算机虚拟为多台逻辑计算机。-
+容器化，把软件代码和所需的所有组件例如库、框架和其他依赖项打包在一起，隔离在自己的容器中。
+
+
+但这就是技术之争，我们认为虚拟化不是未来，容器化才是，不是说我们不支持集团战略，是我们认为这个技术方向如果抹杀掉了，对阿里未来在技术领先上会有一些影响，所以我们希望两条路都保持。当时有很大冲突，但反正我们还是顶住了压力，就一直没用。
+
+极客时间：感觉你们团队的价值当时不是很受认可啊，会不会因为公司当年正飞速发展，大家对成本的关注都很少？
+
+毕玄：对，他们觉得你们搞这？搞啥呢？但正明还是很支持我，他是个偏技术化的人。
+
+说实话如果站在公司整个业务层面看，我也会认为没有太大意义，但我站在公司几年后看又觉得还是得干。反正我很坚持。他们尽管有些也反对，但他们觉得你要干，好像也拦不住你，加上又有人支持，算了你干吧。
+
+所以就干了好多年，准确来讲我一直带着，尽管后来还带了其他团队，但这件事都在我手上。
+
+极客时间：当时又是前期走弯路，又是集团的压力，你为什么会那么坚定要把这个项目做下去？
+
+毕玄：就是技术走向的判断问题。对于云来讲，它确实要走虚拟化，而不是走容器化，否则它没办法对外提供，但是我们认为虚拟化的未来是走向容器化。
+
+因为淘系我们最早就是虚拟化，之前也试过一虚三但是利用率还很低，继续试发现内存超卖不好弄，才到容器化T4。所以我们相当于从虚拟化推进到了容器化，然后你们说要支持云，只做虚拟化，那我们技术的人当然不同意。
+
+除非行政命令，集团说必须不允许搞，那我们只能认。但内部一定会引发非常大的反弹，因为技术的人最反对行政命令，我们讲的你没有认可，举着一个战略就说要站在战略的角度，虽然我们也能理解，但技术一定会去争取，我们说，我们会在内网掀起讨论。
+
+其实内网之前专门有过讨论，简直火爆到吵架了，因为对技术走向的判断本来就很主观，我说是这样，他觉得不是这样，这是没法聊的。当时斗得确实比较厉害，很多人认为我是最反对阿里云的代表，因为阻止了他们把技术体系推进到淘系，而淘系又是最大的规模。其实不是，但反正也就这么过去了。
+
+极客时间：你们能这么坚决，有没有部分原因是你跟多隆搞了小半年，确实有成果能拿出来？
+
+毕玄：效果非常好，所以我们觉得这一定是未来。
+
+极客时间：你判断这是未来，除了有些成果，还有没有别的？比如说外界参考？
+
+毕玄：外界没有，Google都很保密，纯属我们觉得就是这样子。
+
+极客时间：既然有成果，当时你们没有拿成果去跟淘宝总裁说，T4这个技术方向很有效果而且一定是未来？
+
+毕玄：但没用的，我也承认这个决定很难做的，因为一站在集团角度支持云是正确，可能更值得，二站在技术角度他没有办法判断，这就很难决策，所以最后他就不决策了，不决策相当于是保护了我们。
+
+因为他们也确实害怕技术人员的反弹，技术人员会觉得信仰被冲击了，是很可怕的。就像为什么语言之争有些时候会上升得很夸张，对他来讲这是信仰，你不能突破我的信仰。技术方向趋势这种东西本来就很主观，不到那一天你怎么知道，所以两个人聊是不可能聊到一起的。
+
+极客时间：总的来看，你们的团队方向和集团大力倡导的方向不一致，能做起来确实是够幸运的。因为对大厂来说，比如一个方向很好，它业务特别庞大，用了是不是就会变成大方向？
+
+毕玄：对。但后来因为Docker起来了，也不需要再说什么，自然能得到大力支持。
+
+
+
+
+
+　
+
+极客时间：后来Docker起来了，我记得你们把T4和Docker的技术做融合了，那个时候有波折吗？
+
+毕玄：那不会，都是我带的团队，我们坚信这两个东西应该合掉，因为Docker还是有做得很好的地方。
+
+极客时间：是T4去融合Docker还是反过来？
+
+毕玄：最早是T4融合Docker，做了阿里Docker，然后包括开源的Pouch。但这也是我自己当时的判断，我觉得阿里需要坚定地把容器相关的技术多掌握一些，不要过度依赖Docker。
+
+原因是我当时从整体看，觉得Docker未来可能比较危险。从竞争角度上讲，Google在不断地让Docker剥离化，想把Docker变成一个标准实现，这是Google的诉求，如果按这个趋势发展，Docker这家公司能不能活下去可能会成为一个问题，如果他活不下去，我觉得这个世界会需要另外一个标准，阿里是有机会的。
+
+所以我当时让团队一直保留这个可能性，现在应该还是有可能性。但这是很主观的，因为团队很多人希望不要自己搞，全部基于Docker算了，包括高层也有很多声音。但我觉得对阿里来讲，还是值得保留在这方面的能力，因为你是一家做云计算厂商的公司，你不是一家单纯用的公司。
+
+极客时间：你的这种判断力，不管是前面对T4方向的坚信，还是对Docker可能被Google边缘化的分析，后来都印证是对的，是不是大家说的技术方向感？
+
+毕玄：对技术Leader来讲，其实判断是对是错不重要，因为对方向的判断是很主观的，没到那个时候很难说谁对谁错。但最怕你没有判断，外面怎么样，你觉得就是怎么样，那这就不要干了。
+
+有想法，没问题，你可以说你为什么这么觉得，我可以说我为什么这么觉得，两个人至少都可以抛出来讨论，实在达不成一致也没关系，这很正常，反正最后没有办法达成决定，说白了就是看谁地位高，谁是团队的大Leader，因为我背了这个职责，那我做这个决定自然也会承担这个责任，但反正大家都说清楚了，也没有什么。
+
+极客时间：那做判断做决策这事，你有什么心得吗？可以多聊一下。
+
+毕玄：还是看你怎么思考，就是之前七公跟我聊的你的出发点很重要，为什么要做这件事。首先你一定要想清楚，你的出发点是为公司更好的发展，如果很多人想明白了就会知道，公司好了你自然会好。
+
+所以站在公司的角度，越高的层级，要考虑的就会越贴近公司的核心，像阿里，我们说越高的层级，越应该去看阿里集团面临了什么挑战？
+
+当然阿里内部有时候也被我们带歪了，后来很多低层级的人上来也讲阿里集团面临了什么挑战，这跟他一毛钱关系都没有。要想好每个位置它的要求是什么，大家不能把位置给搞乱了，因为搞乱了那个位置就没人了，最可怕的是公司组织结构是这样设计的，结果发现所有人都去做别的了，没有人干活，就乱套了。
+
+极客时间：所以是要结合团队和自己的位置，往上看。
+
+毕玄：对，但越高的人他肯定看的就越大，比方说你在云板块，首先你要想做什么能帮助云更好发展，去解决它的问题，然后你觉得跟你团队最相关的可能会是什么。
+
+如果你有了这样的出发点，再就可以讲你自己想做的可能是什么，基于各种判断，比如商业竞争上的，云可能涉及技术趋势上的，业务涉及业务趋势上的，其实都一样。
+
+Leader最重要的说白了确实在赌未来，赌未来一定会走向哪里，这是很重要的，所以我觉得只要自己能逻辑闭环就可以，但闭环其实很难。双方逻辑都闭环，但方向判断不一样的两个人，确实很难达成一致，但这个我们是可以接受的。
+
+极客时间：因为一旦逻辑闭环，会不断地给自己讲这个故事，他就很难插进来新想法？
+
+毕玄：越高级别的人，越大的Leader，肯定是越难被影响，你会觉得他很偏执，建立在自己很强的相信上，否则他很难走到这个位置。这其实没错，如果他太容易被影响，这样的Leader也太可怕了，你今天汇报一下是这样，明天你汇报一下又变了，那完蛋了，这家公司估计也干不下去。所以当Leader最好不要太急做决定。
+
+
+
+
+
+　
+
+极客时间：现在你再回看当年自己T4这种虚拟团队做项目的方式，你会比较推荐吗？自己先看好方向，再私下拉人一起做。
+
+毕玄：其实后来我也不鼓励大家这么做，T4让我觉得纯靠拉虚拟团队去做事是不好的，最好还是组建一个正规团队去做。
+
+极客时间：你说的“不好”是指的哪一点？不好做成事？
+
+毕玄：拉虚拟团队最大的问题是会被认为有个灵魂人物，外面看到的就是一个人，背后的人全部被隐藏掉了。
+
+我们用的都是业余时间，但他在主管那侧没有任何加分，甚至搞不好还减分，因为主管只看主业。所以最后你就会看到，你拉了一个虚拟团队做这个事，最后获得所有东西的人都是你一个人，这就很不好。
+
+但是正规团队就不一样了，对不对？这是团队获得的。以前我也不想带团队，因为以前在阿里，想干什么基本都能用虚拟组织干，没有正规团队其实很爽的，因为你想，你对大家又不负管理责任，大家纯凭梦想，梦想驱动然后去做一件事情，那你做着不是很爽？如果组建团队就不一样了，你必须背上团队责任。
+
+但我后来觉得还是得带团队，你才有可能做对这家公司更大改变的事情，因为纯靠虚拟团队规模也不可能很大。
+
+极客时间：T4的团队规模是多少人？
+
+毕玄：人一直很少，七八个左右，后来到2016年左右才变成一个三四十人的大团队，但那已经是公司层面上大家公认这条技术路线非常重要了。
+
+极客时间：但你前面说一个新项目刚起来的时候，需要先看到一定成绩，这个风险是正规团队能接受的吗？
+
+毕玄：我觉得取决于Leader，比如团队Leader如果能接受把10%的人投入在一个想尝试的或者团队大家觉得很值得尝试的方向。
+
+后来我带600人的团队（系统软件事业/研发效能事业部/中间件）就搞了两个我们认为未来对技术侧很有影响的方向，我们内部叫X方向，然后我跟全员说，愿意的就可以去，但要求是加入的时候也意味着要从原来的团队脱离。这对很多人是很大的挑战。
+
+我也会说清楚，你做这件事情，一年之内想得到很高的绩效评价，说实话可能性基本是零，因为未知方向挑战非常大，问题简直太多了。但作为Leader，我愿意投这样的方向，所以我可以保障你们不会是最后的一档。
+
+极客时间：脱离原团队，不能兼职？
+
+毕玄：我绝对不允许兼职，因为兼职就有退路，这其实相当于考核试探，就看你愿不愿意为梦想买单。否则如果是业余，所有团队都会说有兴趣，反正无所谓嘛，做失败了也没关系，做成功了还白捡一个加分。
+
+极客时间：那风险很大啊，有多少人愿意去？
+
+毕玄：我们发现很成功，有很多同学很满意新方向，也愿意离开自己的位置，甚至有个带着几十人团队的P9，他都愿意放弃原来的团队，加入新项目，七八人去做一个很未知的方向。
+
+极客时间：这挺厉害的，确实能把一些人筛出来。
+
+毕玄：但这个形式后来我发现了很大问题。
+
+极客时间：项目很容易死？
+
+毕玄：很容易死倒不重要，重要的是如果我不带这个团队了会发生什么。因为这是Leader的主动行为，我一不带，大家就会认为这两方向不要搞了，那这帮人一年不就白干了。
+
+所以这种也建议不要随意尝试，除非是组织性的行为，或者是创始人，创始人反正不会走，那没有问题，最怕的是个体的Leader行为。后来我就基本不做这种了，这样的话不管我在不在，都还能持续。
+
+极客时间：有点好奇，X方向现在呢？
+
+毕玄：后来就挂了，有一个应该还在做，但就不会像当时那么多的资源。如果我在，我肯定会保持它，因为他们做到一定成果了，我会加大投入去赌这个全新方向能不能做起来。但这就是Leader的判断，新的Leader可能认为这个方向不是未来，就不做了，都是很主观的。
+
+但从组织激发角度上来讲，我自己觉得这是个很好的方式，我们能看到在这个团队，有些人是非常愿意为梦想承担风险的。
+
+　
+
+水友讨论区
+
+到这里，今天的对谈就暂时结束了，主要聊的是毕玄的第一段转岗成事经历。
+
+做完中间件HSF后他发现自己作为Leader不知道该干什么了，跑去数据平台做了HBase的落地，但做了一阵发现自己没有足够动力，又开始迷茫自己到底该干点啥，结果从书中找到灵感，去做了最早的容器T4。
+
+作为一名技术人员，毕玄从2011年就开始关注业务增速和成本增速了，虽然在现在的大环境下，降本增效成了普遍口号，但当时各公司正处在高速发展期，很多人可能会觉得关注成本没必要，格局不够大，但居安思危，毕竟不影响业务发展的成本控制手段，从设计到落地可能需要好几年才能看到效果。
+
+不知道你对今天对谈的哪个部分更感兴趣，我还是简单列了三条：
+
+
+“一家公司如果不在乎成本的话，迟早有一天成本会超过收入”，关于成本增速和业务增速，你是怎么看的？你的团队/公司有采取什么措施吗？
+“还是得带团队才有可能做对这家公司更大改变的事情”，你有加入过虚拟团队或者未知方向的团队吗？体验如何？
+“其实判断是对是错不重要，因为对方向的判断是很主观的，但最怕你没有判断”，对技术方向的判断，你是怎么看的？你的决策出发点是什么呢？
+
+
+自由发言环节，期待你的想法，我们留言区见。下一讲我们将聊到毕玄作为总架构师做淘宝异地多活的故事。
+
+拓展阅读
+
+1. 这是一扇传送门，今天简单聊到对技术方向的判断力，如果你想了解更多可以去这一讲，我们将专题讨论如何思考技术演进方向。
+
+2. 对HBase感兴趣，可以看这篇阿里技术星球的文章：阿里HBase超详实践总结 | 一文读懂大数据时代的结构化存储
+
+3. 物理机 -> 虚拟化 -> 容器化的演进，毕玄之前写了这篇：回顾过去看IaaS的Next
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/06异地多活：技术圈子的人，见过猪跑很重要.md

@@ -0,0 +1,273 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            06 异地多活：技术圈子的人，见过猪跑很重要
+                            
+你好，我是叶芊。-
+　-
+上一讲主要复盘了容器项目T4从立项到组织、落地的过程，今天我们聊的主题是异地多活，这是毕玄第一次做大的系统级架构演进。-
+　-
+作为14年阿里职业生涯中的三大亮点之一，当时他要面对上千人，做一场世界上完全没有参考方案的架构，大家都认为做得很成功，但身为总架构师的他却说“这个项目我做得不好”。-
+　-
+他遇到了哪些问题？解法上又有哪些缺陷？我们开始今天的复盘会。
+
+
+　-
+极客时间：看你的经历，T4之后就是异地多活了？是你主动的还是被动分配的？
+
+毕玄：说分配的话，异地多活也能算，因为当时刚好是我转岗。
+
+当时2013年T4我做的太难了，集团各种阻力，再加上运维侧支持力度不够，我那个时候在核心系统部正明那，就决定转去运维团队，因为我觉得如果我在运维就可以把T4落地了。
+
+我就去了那边，正好运维的人跟我说现在要做异地多活，要不你来干？因为异地多活在前一年其实失败了。
+
+极客时间：做过一次了？失败是什么原因？
+
+毕玄：淘宝已经做过一次，蚂蚁也做过一次，也失败了，因为技术上还有很多问题没解决掉。所以就任命了两个新的架构师，我负责淘系的异地多活，俊义负责蚂蚁的异地多活。我们俩各自做了一套方案就开始落地了。
+
+异地多活的难点是因为全世界完全没有可参考方案。Google虽然有全球部署，但广告搜索不一样，比较简单，腾讯也有，但腾讯是社交也比较简单，交易类型的网站一家都没有，我们最早本来想看亚马逊，结果发现他也不做了。到这里我们就很痛苦。
+
+我们第一次开会，下面各方技术都问我，这个项目的方案是什么？我说这个方案现在还不知道，等我们先摸索一下。下面全听傻了，说还能这样。所以这个项目就很槽糕，我们花了一年左右来摸索方案到底是什么。
+
+极客时间：一年出方案感觉挺久的，当时你们是怎么做的？
+
+毕玄：做这种大的架构，一般是你首先有了一个系统全貌，其次你有了解决的思路，你就可以大概知道我需要哪些人来帮我，然后你去找各领域的人，告诉他我的思路是这个，你看这个系统里怎么改能做成这样，慢慢拼出一张图。
+
+但是异地多活是我第一次做这么大的，刚开始的时候确实很难，因为你不懂一个这么大的系统它涉及哪些地方，你又没办法让人跟你讲，因为涉及的人太多了，必须要你先提一个思路，然后大家开始探讨。
+
+所以我们先有了个大概想法，但这个想法多成熟肯定是不知道的，只能先做一部分看看。但是因为没有全貌，不知道要改哪些，一开始就漏掉了很多，第一版设计方案最后要上线了我们才发现还有一堆要改的东西漏改了，然后临时去做那堆的方案。所以主要问题就是漏，漏这漏那。
+
+花了半年多，我们逐步把方案试出来了，方案清楚了后面就很简单。但是前面比较难，如果有参考，你也有信心，大概也知道怎么做，一切都会好很多。
+
+
+
+
+
+　
+
+极客时间：边试边做，不会有人质疑你吗？
+
+毕玄：我现在觉得跟信任有很大关系。当时做这个项目，我上面所有的Leader没有一个人过问我，也没有人挑战我，否则一定会很多人挑战，这啥也不知道就敢上线，你胆子也太大了。
+
+极客时间：会不会因为别人没法挑战？他也不知道方案。
+
+毕玄：对，所有人都没有方案，但即使后面有了方案，还是有人会挑战觉得你们这方法也不好，不靠谱，有没有更简单的？但我们比较强硬。
+
+当时异地多活我是面对上千人，做完我刚好P9P10晋升，面试就有人问：这些人都不向你汇报，为什么要听你的？我说最关键的就一点：因为我还掌握着所有人的机器。你要机器是我给你的，我给你的就是异地的机器，所以你必须配合我做异地的方案，如果你不做，我无所谓，但你上线肯定会出问题，反正你想逼我给同一个地方的机器我是给不了的，没有，你找谁都给不了。
+
+极客时间：这好强硬，不会反弹吗？
+
+毕玄：业务方很多抱怨，所以我后来跟很多人总结说，这个项目做得不算非常好。
+
+而且从团队层面上来讲也不好。当然大家都认为很成功，项目组得到了很高的评价，也能看到我因为这个被晋升了，但这个项目里同样被晋升的人太少了，当然还有一些低级别的晋升，但高级别的差不多就我一个。这就是最大的败笔。
+
+一个项目，如果对公司有非常大的价值，理论上应该有非常多的人被晋升，这也是你在公司能更好做成项目很重要的方面，因为各方都获得了利益。你想，如果只有你一个人获得利益，肯定是有问题的。所以异地多活做的整个过程，抱怨非常大，只是因为我们确实相对强势，但这种强势后面其实也会引发一些问题。
+
+极客时间：但最后异地多活也确实是做成了，影响力也比较大，大家可能也没法说什么吧？
+
+毕玄：如果没做成，那肯定挂了。但即使成了，还是会有人有很多看法，这个我也认。
+
+因为对一家公司来讲，以战养兵是最重要的，你一个这么大的战斗，竟然没有培养出很多的人，这确实有问题，我是承认的。
+
+极客时间：没有培养出人？具体是什么原因，人才没有历练到位吗？
+
+毕玄：可能很多是曝光的原因。比如异地多活对外曝光全是我，讲各种方案等等，后来其他的项目比如统一调度，我们就会注意让更多人曝光，哪怕有些演讲看起来好像很不技术，但我们觉得对公司来讲这还是蛮重要的，公司应该看到更多人才。
+
+因为一个这么大的项目，总不可能是一个人就干成了，肯定是有很多人一起，但是就看这些人有没有机会被更多高层知道。说实话高级别晋升，贡献很重要。但高层会认为那不就是他吗？其他人做了什么？高层认为就因为他，所以做成了。其实不是这样。
+
+极客时间：一个项目，对贡献曝光上的关注，是不是参与的人越多，越重要？
+
+毕玄：对做非常大的项目很重要的，越是大项目，越要把大家团结住。
+
+后来再做项目，我就会特别关注参加了这个项目的核心人员，他们情况是什么，有多少人会因为做了这个项目被晋升上去。如果比较多，说明这个项目不仅有个很好的成果，还让整个团队的人得到了很好的成长，那这就是一个非常好的项目。
+
+你想，大家一起做了一个很大的事情，对公司有很大贡献，但是只有你有成绩，下面的人没有被认可，那这些人会很受不了，我明明干了很多事情，最后为什么还是没有得到认可。业务方就更不爽，因为他觉得这又不是我主要的事，浪费了我很多时间，我什么也没得到，然后你们都得到了，替你打工。
+
+再加上光环如果过度集中在一个人身上，那个人会成为众矢之的，肯定是这样。因为其他人会觉得我无非是成就了你，所以后来做很大的项目我们会特别注意，不要塑造一个神，不是好事。
+
+
+
+
+
+　
+
+极客时间：就项目曝光这一点上，现在的技术大会阿里确实会有很多人出来分享，是你说的为了增加曝光吗？
+
+毕玄：对，阿里有几年是高峰，现在可能少一点，都是去站个台。
+
+极客时间：现在不多了是为什么？
+
+毕玄：以前对外分享，内部的定调就是在中国的自由分享，希望跟大家交流，因为技术很需要聊，你的想法可能跟别人不一样，而且可能别人干过，你实际上是想找一个干过的人跟你聊一下，看看自己想的有没有问题。但后来我们只能去树立技术品牌。
+
+极客时间：做技术品牌的转变，是因为什么？你们是什么时候开始做的？
+
+毕玄：2009年。当时我们第一次校招，出去之后打击太大了，因为在09年，我们认为淘宝已经是集团最牛的一家公司了，淘宝的人在阿里横着走，因为说实话其他公司量比我们小非常多，而且我们也逐渐接近盈利，当然觉得自己是最牛的。但我们出去才发现根本不是这么回事。
+
+学生都说，淘宝是什么公司？不就是卖东西的，那你们是不是专门帮人卖货？他们觉得肯定是雅虎、阿里研究院、B2B这些，因为B2B是香港上市公司，他们觉得肯定这几家好。淘宝？除非前几家我都没面过，那我再来你们这试一下。我们就深受打击。
+
+所以淘宝从09年决定做技术品牌建设，就参加了很多技术大会，包括QCon等等都是这个目的。这也是菲青提议的，要树立起淘宝是整个阿里集团技术非常好的一家。
+
+极客时间：开始是交流，到做品牌，现在就站个台？这个变化是为什么？
+
+毕玄：对从出来交流的人你也能看出来，阿里以前参加大会都是相对资深的，高级别的，但现在阿里高级别的人都不出来了。
+
+近几年阿里的风格是，国内都派相对年轻的、有潜质的人练习他的分享表达能力。因为我们觉得工程师要往更高层走，你表达能力必须要的，毕竟你不是一个人做，除非都想成为多隆那样一个人守到底，但在现代化软件下也很难，一个人再强也不行，所以公司肯定需要这种类型的人。
+
+剩下更资深的人都去国外了，拜访顶尖的公司，顶尖的名校。公司，我们只拜访Google、Facebook、AWS这些最顶的，其他的都不太见，他们对我们有兴趣，但我们可能对他们没有兴趣；然后学校，我们去拜访斯坦福、麻省这种规格的。因为后来我们觉得，只有跟这些人聊，互相才有一定的交流空间。
+
+极客时间：交流空间？是指对话背后公司的技术问题吗？
+
+毕玄：因为说实话到现在为止，中国很多公司去拜访Google都没有交流，其实还是个学习状态。包括我前几年带队去Google拜访也还是这种状态，都是我们问Google技术上的挑战，看他们是怎么做的，然后我们问完，问他们对我们有什么问题，没有任何问题，因为Google能从你问的问题推测出你的状况，就没有任何兴趣跟我们聊。
+
+像Facebook就不一样，阿里很明显，以前也几乎全是我们问他问题，但现在Facebook会问我们很多问题，技术地位已经不一样了。
+
+极客时间：推断你的发展水平？
+
+毕玄：对，我们以前问他们很多问题，他们会说这个问题是我们七年前做的什么什么东西，有论文讲过了，你可以去看。这就很尴尬。
+
+跟现在中国很多公司问阿里一样，比如说问分布式，阿里都告诉你我们是在2008年做的，相当于是已经是14年前了，那你觉得，对阿里来讲，讨论这个问题有多大意义？就没有了，因为阿里觉得我已经成功，不想跟你们讨论这些了。所以这就是纯单向交流，双向要求很高的。
+
+这几年特别明显，很多大公司都这样，因为他们的水平确实已经能跟国外顶级对话，对国内的很多交流就没有任何兴趣。有一些公司愿意去，肯定是为了别的目的，比如说卖货这种商业诉求，才去做纯单向。
+
+极客时间：不只是讲的人没兴趣，听的人如果没有那个场景不遇到那个技术问题，是不是也听不明白？
+
+毕玄：听的人，听完也只是觉得啊好牛，然后就没有然后了，就走了。
+
+所以最高质量的交流肯定是一个非常小的圈子。但那个小圈子是很难进的。我后来带团队都说，比如去硅谷，如果你能找到硅谷这个领域最顶级的一帮人，大家一起吃个饭，这就决定了你有没有进圈。
+
+其实所有的顶级领域最后都是混圈。只不过计算机的这个圈子相对来讲更难靠“混”混进去，因为这个圈子的人彼此文人相轻，他关键看你做过什么，不会因为你是某公司负责某团队的人就觉得你很牛，不会的。所以混进技术圈子难度太大，但你如果能进这个圈子，说明你确实得到一定的认可。
+
+　
+
+
+
+　
+
+极客时间：混到这种顶级圈里能拿到什么？一些前沿问题的参考方案？像异地多活当时因为没有参考方案踩坑很多。
+
+毕玄：对。因为面对一个问题，如果你不知道这个世界上已经有的、最好的解决方法到底有哪些，你就会觉得自己的解决特别牛，但其实可能是别人玩剩的。
+
+架构跟写代码不同，架构最大的问题是如果解决思路有问题，最后的返工可能非常吓人。
+
+阿里在这个地方犯过无数错误。以前做分布式的时候，我们只知道要做成分布式，但我们没有想清楚，一个公司的整个系统换成分布式以后，对团队会带来什么挑战？会有哪些问题？这些如果在架构层面没有解决，后面再解决就很难。
+
+现在我们会说“见过猪跑是很重要的”。以前我们觉得见过猪跑有什么重要的，反正我现在没想好，以后可以再补嘛，我可以慢慢练成见过猪跑。但是架构这玩意，你现在没看到，未来要补的时候代价可能极大。所以架构师，对视野的要求非常高。
+
+极客时间：架构的“看到”和“做到”，哪个要求会更高一点？
+
+毕玄：不是一个维度，因为“看到”有些时候是经历问题，另一个就是天花板问题，你有没有办法知道天花板。
+
+中国其实很多人并不知道天花板，有人会说看一些大会就可以了，认为大会展示的是天花板。但其实可能根本不是。而且现在大会里还有很多商业目的，就更完蛋，其实他就是忽悠你的，在带节奏，但你不一定知道，因为你外行，这很正常。
+
+极客时间：那你们去哪里看天花板？
+
+毕玄：其实要看学术论文。你看Google对这个世界的影响，在技术基础层面影响非常非常大，但它所有影响都体现在哪里？不是技术大会，是它发表的论文，虽然大家老觉得发学术论文都是忽悠，但必须说，真正改变这个世界技术的都是学术论文。只不过学术论文里你也要挑，因为混的确实也很多。
+
+极客时间：挑论文，有什么具体方法可以讲讲吗？
+
+毕玄：最简单的办法，当然是先找你的领域含金量最高的学术会议，因为他论文的水分相对低一点，而且工程界的也会去那发，像Google发论文，很大目的是为了让他们那几个人去评美国的科学院院士，否则工程界的人根本不想写论文的，没有必要，但要评院士他就必须写，就写了那几篇。
+
+看这种论文，第一你可以大概判断一下方向，因为在这种含金量很高的会议上，他发的论文肯定解他的问题，非常具备前瞻性，或者非常具备挑战，或者价值非常大；第二他解决的方法肯定是论证过的，也具备一定创新的。因为论文要的是创新，不能说和别人解过的一样。
+
+加上工程届的论文，因为是工程公司发的，像Google这种公司都是工程类，他肯定会有实践兜底。当然必须说有真有假，既使Google也是，他以前还发过Omega之类的调度系论文，但Omega根本就没有大规模应用，他讲的是很美好的一个东西。
+
+技术上是可以编的，但你最后要了解一下工程上它到底怎么落地，到底碰了什么障碍。这些肯定不会在论文里讲，你需要自己验证，你会听到很多声音，因为技术圈声音很多，有真有假，这就取决于你自己有没有能力判断。学术论文也一样，你要跟这些教授直接去聊或者侧面打听到底什么情况。
+
+极客时间：为了看到天花板，成本应该挺高的，淘宝是怎么做的？
+
+毕玄：以前我们每年会专门关注这种顶级大会，不断研究里面发表的所有论文，去判断我们在这个问题上现在的解决方案跟他们对比大概是什么情况，未来是不是有更创新的方向可以去尝试。
+
+因为对公司来讲，如果一个架构师不知道天花板，肯定不是个足够好的架构师。以前很多人会在PPT上写，我的解决方案是全世界最好的，但你得说清楚你为什么最好，如果你有论证，那我们可以认。
+
+或者你说现在不是最好的，但你知道自己的位置，这种也可以，因为这个跟你公司的工程状况有关，工程落地是有节奏问题的，知道最好的是那样，只是我现在做不到，没关系，所有人都这样。如果知道天花板了，就不怕，不知道，你可能也不怕，但是对公司来讲就是一个很可怕的不怕。
+
+极客时间：你有怕的阶段吗，当时做异地多活就没有参考方案？
+
+毕玄：我也不太怕，因为我觉得大不了自己折腾。像2013年做异地多活，我们心里当然有担心，但关键是这个问题对公司来讲是一定要解决的，那就没啥，那就试。
+
+因为工程说白了，毕竟不是科学难题，做工程，实在不行是可以试出来的，只是节奏会长，而且有可能不那么可控，成本比较高。这个主要看信不信，你自己觉得可以搞，就可以。
+
+极客时间：那你们招人的时候，会对天花板的认知有要求吗？
+
+毕玄：我们面试判断的核心就是看你对自己项目背后技术的理解程度，包括这个项目的问题、你的解法、业界对这个问题的解法、最后你为什么选择了这个方法而没有选择业界的方法。
+
+极客时间：这个要求高吗？
+
+毕玄：非常高，如果你能回答得非常好，说明你的选择做得非常理性，这种我们觉得简直是太完美的候选人了。
+
+但事实上知道天花板的人很少了，这是要花精力的。很多人不愿意干，觉得没有必要，不就是个需求？我干了就行了，你管我怎么干的，先不先进什么的都不重要。但是有些对技术非常有热情的人，他其实很有兴趣去了解，这个差别非常大的，而且很明显。
+
+
+
+
+
+　
+
+极客时间：天花板的问题，因为阿里是大公司，有资源可以让大家去国外去交流，但是很多中小公司没有，怎么办？
+
+毕玄：我们觉得也可以关注，不一定要跟别人直接聊，但是大概要知道一下，比如顶会论文现在都在探讨什么问题，有什么创新性的解决方法。
+
+如果你发现，顶会论文关注的领域跟你的领域一毛钱关系都没有，这说明他们认为这个领域目前没有什么可突破的空间，那就要赶快想下一步了。
+
+极客时间：这是需要主动去关注？
+
+毕玄：那必须主动，被动不可能的。架构师没法被动。
+
+极客时间：但是有些架构师可能是被安排上去的，对天花板的了解不是很好，怎么办？
+
+毕玄：这也确实存在，你被推到了这个位置，不得不去解决这个问题。有些人是这样成长起来的，很正常。
+
+但这就太看命了，而且对公司来讲，可能会稍微有点问题，因为问题你是解了，但是解法可能有问题，最后会给公司埋下巨大的坑。
+
+所以回顾当年，大家都觉得淘宝做得特别好，但事实上我们一帮人看，都觉得自己做的简直了糟糕到不行，有些就是我们当时埋下的坑。但如果让我们再去做，会完全不一样，这说明我们确实比当年更好，因为我们现在是见过猪跑的，也知道天花板在哪里。
+
+当年我们其实是知道一些东西的，包括Google发的一些论文。但当时我们看了很多觉得做这个没有意义，这就是我们的判断，过了几年后就发现，我们确实错了（笑），其实是很有意义的。
+
+极客时间：有没有部分原因是你们的业务没有到那个地步，还认识不到Google讲的东西的意义？
+
+毕玄：不是的，我们当时也快出现那个问题了，但是我们没有判断出来到底会有多严重。但Google是经历过的，我们其实应该相信的，要相信一个见过猪跑的人他说的是对的，不要太自以为是，觉得自己想的会比他更好。
+
+工程的很多问题，没有经历，凭空想是想不出来的，比如阿里这么大体量，他在技术上到底面临了什么问题，我们在里面都不一定能想得出这个问题是啥，外围就更不提。所以很多人很难成长起来，因为做一个商业系统的机会就很少，你说你在家里想一个商业的系统是怎么做出来的，会面临什么问题，说实话这就是空想，跟这些真正经历过的人去比是不大可能的。
+
+　
+
+水友讨论区
+
+对谈到这里就暂时结束了，主要聊的是当年毕玄那伙人做异地多活的故事。
+
+异地多活的技术资料阿里之前公开很多了，这次访谈没有太细致地聊这一话题（如果你对技术细节感兴趣，可以看看拓展阅读的链接），重点放在了对整个项目的复盘，从牵头，到具体落地，到收尾，以及后期曝光的全过程。
+
+在对谈中，我印象最深刻的是很多人觉得异地多活做的很成功，但他却反思自己做项目的方法有很大缺陷，强调做大项目不要塑造一个神，不是好事。
+
+
+“在公司能更好做成项目，很重要的方面是各方都要获得利益”，关于这一点，你怎么看呢？在自己参与的项目里，或者见证过别人的项目，你有相关案例可以分享讨论吗？
+
+
+另外今天也重点聊到架构师如何拓展视野，毕玄认为“对架构师来说，见过猪跑是很重要的”，总结架构师会面临两大困境：没见过猪跑的经历缺陷、对天花板认知的不足。
+
+
+对这两个问题，你怎么看？平时是怎么处理的呢？
+关于天花板问题，毕玄的建议是先找自己的领域含金量最高的学术会议，如果你有兴趣也有这方面的需求，可以实操一下，如果有帮助，记得回来还愿 :)
+
+
+如果你有其他有感想的话题，欢迎留言，参与讨论，说不定在留言区你能结识同领域的开发者哦。
+
+下一讲我们将讨论毕玄的第二大段转岗经历——研发转运维，这段经历我觉得影响了他后面的整个职业发展，下一讲见。
+
+拓展阅读
+
+1. 这是一扇传送门，后面有一讲我们会专门讨论架构师到底该怎么提升，毕玄也“被迫”总结了一些方法论，期待和你再会。
+
+2. 如果你对天花板感兴趣，可以看这篇毕玄之前写的拓宽技术视野的方法论：如何避免成为井底之蛙
+
+3. 异地多活的具体技术细节，感兴趣可以看这个来自阿里开发者的链接：“异地多活”设计辣么难？其实是你想多了！
+
+4. 之前InfoQ也就异地多活的项目采访过毕玄：从冷备到多活，阿里毕玄谈数据中心的异地容灾
+
+5. 《超级访谈：对话张雪峰》中也提到饿了么做异地多活的经历：不够坚定：异地多活没有一步到位的遗憾
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/07运维团队：我能干，只是我不想干而已.md

@@ -0,0 +1,303 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            07 运维团队：我能干，只是我不想干而已
+                            
+你好，我是叶芊。-
+　-
+上一讲我们聊到异地多活，毕玄说他能做其实是因为自己正好转岗去运维了，但是从研发转岗到运维？这似乎也是一个不太寻常的职业方向横跳。-
+　-
+作为阿里整个运维团队的Leader，我们问他对普遍存在的研发-运维岗位认知鄙视链是怎么处理的，他却说：“说实话，我也觉得解决不了。”-
+　-
+运维团队面对的究竟是什么样的难题？又是如何置死地而后生找到了自己的团队价值呢？
+
+
+　-
+极客时间：异地多活的时候你就已经转去运维团队了，去了以后你觉得外界对运维最大的误解是什么？
+
+毕玄：我以前是研发线的，研发线会觉得运维没有什么技术含量，解决不了的，还是要研发解。
+
+说白了，大多数研发都认为像运维、测试，我完全可以干，之所以我不干，只是因为我不想干而已，但研发这活不是你能干的。如果有专业壁垒就不一样，比如研发对数据库就不会这么看，因为他觉得你那活我确实干不了（笑）。所以他自然会觉得我在鄙视链的上游，你运维在下游，很正常。但我去做运维以后，就跟很多人说真的不是这样。
+
+运维是一个知识面非常广的岗位。如果你做研发，说实话知识面很窄的，很可能连你的代码在哪个机房、机型是什么、什么样的网络条件、运行环境是什么样的都不知道。我以前刚到运维团队的时候去开会，他们说的是啥我都不知道。
+
+极客时间：像机房、网络条件等等，研发会不会觉得这也不用太关注？
+
+毕玄：这全部是基础设施，但如果你不知道，做系统设计的时候可能有很多偏差。
+
+后来我去了运维才了解，可能研发你说一句话，运维为了满足你这个条件，花了很多的钱，但你如果在软件侧简单改一下，这个钱其实根本不用花。
+
+但研发人也不懂，运维的人也不懂，他不知道原来你软件稍微改一下，这个需求就没有了，他觉得你可能是个合理需求，然后就去干，这就悲剧了，两个没法对话。因为运维如果没有足够的理由去挑战，那研发侧肯定认为我干嘛要改？所以后来我们去跟很多研发说，要整体看一下成本投入，那研发很多就懂了。
+
+极客时间：还有什么新的认知吗？
+
+毕玄：还有对基础设施的了解。其实阿里后来做的很多创新是因为我们对基础设施演进的了解。
+
+异地多活不用说，比如后来我们做统一调度，对整个基础设施有很多改造。因为对网络有了一定概念，知道网络带宽在不断演进，原来是万兆，现在能到25G、40G、100G；以前认为两台机器之间网络带宽太小，在软件侧做了很多东西，其实现在是不需要的；因为网络可以支持，才有了现在的计算存储分离等等。
+
+如果软件的人不懂这些，他根本就想不到很多基础侧的创新。硬件也一样，虚拟化下沉到另外一块芯片上，是因为他对物理机型有更多了解，知道了可能性是具备的，不光是从存量来看，也能从运行环境各个方面来看。
+
+这都是因为这些人知识面非常广，如果你了解很多，整个创新其实能做得非常好。
+
+极客时间：因为了解，才有可能性？
+
+毕玄：对，我们之前也觉得做基础设施的人啥也不懂，因为研发始终认为自己是最牛的，除了业务以外，技术线研发肯定是站在顶端的，觉得其他所有人都是为我做配套的而已。
+
+但是如果你不知道网络可以这么变，不可能敢提出在软件侧要做计算分离这种事，因为他根本就不可能实现，很多都是这样，包括基础设施的大机房建设等等。
+
+所以我自己觉得运维这段经历，一是让我做了异地多活，这还是挺重要的，因为我以前没做过这么大的，也基本不涉及业务，我算是做了异地多活，大家才觉得你是能做整个大系统架构的人，都认可你是可以的。第二个就是知识面的拓宽，我终于知道了一个系统真正的全貌，因为系统事实上都涉及基础设施，其实你也逃不掉的。我们可能认为好像不用管基础设施，但事实上如果不管，软件设计或多或少会有点问题，就不是那么合理。
+
+　
+
+
+
+　
+
+极客时间：异地多活之后，阿里有些运维侧工具就起来了，你是参与了吗？
+
+毕玄：我是2015年下半年开始带整个运维团队的，当时想让这个团队发生一些变化。
+
+运维以前很苦，几乎所有涉及线上操作的工作全都是运维团队做，一天发几百个系统，根本没法干活，虽然发布也是一套系统，但必须要人点，线上还要盯着看，如果有问题还要查问题，背后还有机器管理等等，杂事非常多。
+
+以前有个比例，1个一线运维要对100多个研发，所以他每天光是回答问题，比如机器在哪、怎么用各种，不用干别的就满了，所以非常苦。但是大家又总觉得，你们运维既然这么苦，为什么不做一些工具解放自己？是不是不想？是不是没有研发技能？
+
+我去了才知道，说实话多数运维做工具的技能还是有的，但事实是他每天根本没有时间做工具。因为研发是很需要连续性状态的，写代码的人都明白，你不能说写个十分钟，被IM弹出一个消息，回复完，半个小时后好不容易进入上下文，结果又被打乱，那代码就没法写了。
+
+后来我就跟很多人说，那是因为你没干运维这个事，你去了之后会发现你也没空。以后中国的运维大会，可以让一线运维的人来个吐槽环节，绝对能把研发喷死。
+
+极客时间：因为比例不够，每天杂事多，太忙没时间做工具，就一直在给支持。
+
+毕玄：对，恶性循环。因为理论上你讲如果运维有很好的工具给研发，他是不会问你问题的，但是这是个悖论。
+
+而且阿里当时也有专门的运维工具团队，就是我带的，但通常来讲业务运维团队跟运维工具团队很容易产生矛盾。
+
+极客时间：运维工具团队给业务运维做工具不是很好吗，解掉刚才说的没时间做工具的死循环，为什么会有矛盾？
+
+毕玄：运维会觉得你工具团队做的东西不满足运维的需求，但是他们一天到晚实在太忙，工具如果不好用，他觉得我还不如手工，因为如果已经习惯了，其实手工效率也不会太低。但是工具需要成熟又需要不断使用。
+
+所以这个局面，让运维这一侧的我们都觉得运维团队未来会越来越难，成长空间很有限，因为干杂活怎么有成长空间，但活又很重，对一家公司来讲，没有这样的人不行。但有了，大家又觉得这批人好像技能不行。
+
+这样恶性循环下去的话，之后一定谁也不想干了，这么苦而且还全是责任。你想，运维不出问题没什么，不出问题大家觉得这个部门不存在，但一出问题，第一眼看到的就是运维。
+
+极客时间：那你15年带这个团队的时候，做了什么？
+
+毕玄：当时我们就在讨论这个团队未来到底走向什么地方，这是一个非常纠结的话题，这也是后来让我去带整个团队很大的原因，我们想，既然工具和运维很容易矛盾，那干脆合成一个团队得了，探索一下，看看能不能解决。
+
+极客时间：合并之后，探索了哪些方法？
+
+毕玄：我带以后，说实话我也觉得解决不了。
+
+我当时接手最早的想法就是，让每个人一天腾出20%的时间来做一些工具的研发，后来发现这根本就不现实。但很多人就觉得是你们团队自己不想或者没有能力解救自己，肯定不是，只是因为有很多现实问题。包括运维的人，你说他不想？他自己当然也想，谁都不愿意每天就做一些很碎片化的工作，大家都想解救自己。
+
+当时Google的SRE，大家都觉得是最好的团队对不对？但是如果你仔细看，关键一他的人多数来自以前非常资深的研发，根本就不是运维岗，那他和研发沟通，包括研发技能，肯定没有问题。第二至少我们外部得到的消息是，他们的人每天可以腾出30%的时间用来做研发类型的工作，而不是运维类型的工作，那就不一样了。
+
+极客时间：Google他们的时间是怎么来的？
+
+毕玄：比例问题。如果能有一定的运维研发比例，让运维有时间去学习一些开发的技能，为自己写工具，这肯定满足需求。但是有多少公司能接受运维跟研发的比率是成一定比例？现在蚂蚁是接受的，所以蚂蚁跟阿里不一样。
+
+极客时间：运维研发比例问题本质是什么？
+
+毕玄：其实是分工，就是运维到底是做什么的，这个认知。
+
+比如说蚂蚁现在的安全生产团队，核心指标是整个系统全年的系统稳定性、资损情况，其他不承担的，很多让研发自己做掉。这样有了专业分工，运维团队相当于跟研发团队没有太大区别，只是业务研发团队做的是业务需求，你运维团队做的是运维业务的需求。
+
+但之前，分工上大家就一直觉得运维是给支持的，再加上传统运维确实做了很多偏执行的工作。我不知道中国其他公司的状况是什么，反正在阿里，我们觉得这条路很难走。
+
+
+
+
+
+　
+
+极客时间：在阿里很难走是为什么，当时运维团队的价值当时没有被看到？可以详细说下当时做了哪些尝试吗？
+
+毕玄：我们本来希望能跟集团谈一个数，比如运维就是一比多少研发，你不要老挑战我的人多。因为大家都觉得运维团队人很多。
+
+我带的时候运维团队有一两百人，但是研发十几个人就能做一个非常核心的系统，所以研发团队看你，会觉得你比他人还多，运维动辄上百人，还说不够。问题是他没有想到我们是整个集团的运维，我们还觉得一两百人怎么够，得四五百更多。但这上面一看，你们有这么多人。
+
+另外就是你说的，运维的价值其实很难被衡量，它的价值到底是什么？
+
+因为运维不像研发，研发直接面对业务，做的东西价值是可以被论证的，只要这个业务好，研发肯定有贡献。但运维到底做了什么？我说运维很核心的工作是保护整个系统的稳定，另外是成本控制，但这些都没有业务那么耀眼，而且保护稳定这种事，不出问题是没有人知道的，就跟安全团队一样，也是很痛苦的团队。
+
+极客时间：蚂蚁论证了运维价值这个事？
+
+毕玄：为什么蚂蚁能搞定，是因为后来蚂蚁出过一些故障，阿里也出了，但蚂蚁对故障的重视度必须说比阿里高非常多。
+
+因为蚂蚁是金融，如果它出故障，首先可能会引发用户的信任问题，第二会引发监管的问题，监管就是生命线，那对他们来讲就不是开玩笑的。所以蚂蚁会觉得我得力保稳定。
+
+现在俊义带着的安全生产团队就是一个固定比例，每年不用申请运维名额的，研发你涨我就涨，非常简单。你想，一个固定比率，大家肯定不会一天到晚总那么饱满，就可以在日常工作以外，腾出时间做工具研发，把自己解放出来。其实这样就会越来越好，是个良性循环，但它需要时间。
+
+所以我们当时想跟集团说定一个比例，然后团队要转型也需要一段时间，需要接受这段时间里人是比别人多的。
+
+极客时间：比例的事，集团批了吗？
+
+毕玄：没有。我带了半年多，也试了一些其他方法，但这个问题在阿里太难解决了，所有人都这么觉得。
+
+虽然我们知道Google大概是怎么做的，但都学不出来，而且那个时候蚂蚁也没有搞定运维和研发一比多少的问题，他们也是后来出了几次大故障以后，公司才觉得这是生命线。
+
+当时我就觉得，我很难带领这个团队完成一次组织转型。我们是希望完成组织转型和升级的，向Google靠拢，变成一个非常资深的团队，能更专注做好工具研发，或者维护整个系统的稳定，因为SRE的定义准确讲是维护系统稳定，而不是什么发布、运维答疑这种杂活，但在中国绝大部分公司，我估计运维团队都是这个角色。
+
+　
+
+
+
+　
+
+极客时间：这组织转型不了，你当时是怎么办的？
+
+毕玄：到16年这个问题太难解决了，当时正好行癫来任集团CTO，我们商量了一下，这么搞下去反正也解决不了问题，就提出了一个方案：把运维工作直接交还给研发，解散掉统一的运维团队，把运维还给了所有的BU，比如一部分人是支持淘宝的，一部分人支持搜索等等，按照BU把人全部还给研发，相当于没有了统一的运维团队。
+
+等到分人的时候，所有人终于知道了，哦你们人确实太少了。以前他们觉得你怎么那么多人，但是现在大家摊在一张纸上来看好了，反正就是这个状况，支持你部门的人其实就1、2个人。
+
+极客时间：这种拆分是怎么落的？
+
+毕玄：就是直接决定组织拆分。
+
+极客时间：搞了多久？
+
+毕玄：应该是一个月就搞定了。
+
+极客时间：会给这一批人选择吗，比如说哪个业务去多少个人？
+
+毕玄：没有选择，你以前对的哪个BU，现在你当然怎么分。不过因为拆的过程太粗暴，当时也引发了一波离职，导致有段时间运维很混乱，加上分散了人也不够，另外工具确实也比较缺失，各家BU又开始自己做工具，因为各家也受不了。
+
+极客时间：直接组织拆分这一下够狠的，你们当时想到这个结果了吗？
+
+毕玄：我们能想到，但是还是可以接受。
+
+因为我们认为只有这样，才有可能让研发承担掉一些很杂碎的运维工作，形成这个习惯，也希望让所有研发都至少知道你的代码跑在哪些机器上、这些机器在哪里、大概环境是什么。其他的方式很难做到这一点，你只要有个团队在这，研发就不可能去做。
+
+你想，一个BU发现自己只有1、2个运维的时候，他们肯定也觉得人少，就会开始让部分研发承担运维的工作，这就是我们想要的，当然研发吐槽就很多了。反正我们觉得大思路上，想象的最后样子没有问题，但是怎么走到那个样子是个很大的挑战。
+
+极客时间：选择组织拆分这种自损八百的方案，也是你们在15年到16年没跑通其他的方案？
+
+毕玄：因为最早大家能想到的方案肯定都是做一套很好的工具，研发用工具完成一些碎片工作，然后运维团队就可以像SRE一样很专注地去看系统稳定性，但我们当时看，这就偏理想化。因为这么走，第一你要先人员扩张。
+
+极客时间：集团不给批，所以做不到。
+
+毕玄：对，这第一步就很难，我的人是要翻倍的，但这个对公司来说……
+
+极客时间：那统一的运维拆到每个BU之后，BU他们自己又开始做很多工具。
+
+毕玄：对，工具又乱七八糟的。因为说实话工具重复做，意义很小，很多工具很类似，所以以前希望统一。
+
+极客时间：以前运维团队统一的目的是什么？
+
+毕玄：最早应该是只有淘宝，因为就一家公司，它肯定是一个，但后来大家觉得淘宝双11的模式做得非常好，希望淘宝的经验可以去覆盖掉其他的，所以慢慢就把各家的运维全部合掉了。
+
+统一的目的，一是相对来讲人效肯定是最好的，二是理论上你可以做统一工作来解决很多问题，运维尤其，这样基础设施能更好地统一演进，如果分散了没有规模，很多事情就很难搞。
+
+比如A业务说我的业务，我要这样的机器，B业务说我要另外一台机器，因为业务方就是这样，什么对我最好，那我就要这样，但对后面设施的采购、维护都是极大的问题。如果能统一运维，还能节省成本，这个机器可能在你这个业务上浪费了点钱，但在全盘里其实是省钱的。但这件事，你如果没有统一的团队，太难做了。
+
+极客时间：很多工具起来之后，效率和成本都不好，有把它们合在一起吗？
+
+毕玄：后来我不太管这个事，我知道分散造成了很多问题，但现在好像想统一了，鲁肃下面又成立了SRE团队，各个运维团队开始归拢了。
+
+所以阿里对我们当年拆掉运维有很多争议，非常多，因为大家觉得现在的乱象就是我们当年那么暴力造成的。这个我们也认了，但我们觉得关键是没有解法。
+
+而且现在合并，跟我们当年不一样，因为运维团队的职责变了，研发已经接受了。我们当年其实也是这样想的，我先拆一下，让大家习惯，后面我可以再整合，但职责就变了，只做全局稳定性的维护、机器管理这些。
+
+极客时间：所以从组织演进的这个角度来看，当时拆分团队的核心目标也是达成了？
+
+毕玄：算的，至少现在SRE团队比当年的运维团队好很多，他们很多人合进去了觉得工作的挺开心，不像以前运维的人，简直是太苦了，他的情绪永远不是很好，压力又非常大。因为如果出故障，那不得了，运维绝对是第一个被问责的，但很多又可能是研发的代码系统设计问题，这个你又负不了责，这就很尴尬。所以研发总觉得运维没啥用，但事实上又离不开。
+
+
+
+
+
+　
+
+极客时间：经过运维团队的合并和拆分这一招，这么看研发和运维的分工方式，是不是最开始就不太行？
+
+毕玄：是有点问题。你想，最早是一家创业小公司的时候，是不会有这个分工的，肯定是从头做到尾，写代码，自己发布上线，维护，全都是自己干。我2007年进淘宝的时候，发所有系统也都是我跟运维一起，没有说什么交给他了就不管了，没有，绝对不可能的。
+
+后来某阿里高管有个形象的比喻，他说：你看你们现在，简直活得像大爷一样，写完代码就有一帮人服侍你，什么PM、研发效能、测试、运维，他们好像就是你们的保姆一样，你们写完就什么都不管了，什么都不知道。
+
+所以从原则上讲，虽然我们觉得拆分运维团队这个动作是有点不大合理，但至少逼着研发提升了自己的技能，很多研发是不爽，但如果从他职业生涯来看，我们觉得不是坏事，你技能变好了，对不对？
+
+极客时间：但研发应该会压力比较大吧？
+
+毕玄：研发的抱怨其实差不多，我活已经很多了，每天要接一堆很碎片的需求，你们现在不想干，把活都扔给我们，包括测试团队当时也是希望研发自测，然后自己更多的做工具。所以研发那会觉得我不仅要管这些，还得管上线、发布后的整个状况，你们这些团队就是啥活都不想干，什么都扔给我们。
+
+但研发你未来作为一个系统的掌控者，这些本来就应该知道的，也本来要掌握的，你做系统设计，不可能忽视下面的基础设施完全当它是个黑盒，不可能，就算现在是云，你也不可能把它当黑盒用，对你还得是个白盒。
+
+极客时间：所以阿里强拆一定程度上解决了这个问题，但不能轻易用。
+
+毕玄：必须要有很高的支持，因为这个动作非常大，会影响所有团队，内部肯定会有各种意见。
+
+但我们认为组织演进的路线是什么？你不能说虽然团队的人整体都没有成长，但这样对公司是最好的。这样最大问题是团队会很难活下去，长期一定是个问题，一是不稳定离职率会很高，你老换人，研发线他每次找你也很痛苦，而且也很危险，公司哪天想换掉你很简单。
+
+每个团队可能都要想一下成长空间问题，很重要的，因为不可能说公司哪个团队是个弃子。
+
+　
+
+
+
+　
+
+极客时间：看未来，你觉得运维可能会往哪个方面发展？
+
+毕玄：我现在觉得，大厂的模式还是不错的，研发应该干掉运维的一些工作。
+
+但这个前提确实是公司在运维侧的工具上要有一定的积累。如果你完全没有积累，按我们当年那么粗暴，也会引发问题，一定会有一段时间很崩溃。当然过了那段时间可能会工具百花齐放，但之后基础设施怎么统一又是一个问题。
+
+但大厂的模式也有一个问题，对研发的技能要求太高了，就相当于研发你要懂运维。但从现实的人才池子来讲，这一点又很难实现，现实中多数研发其实不懂运维。
+
+极客时间：小厂应该更是。
+
+毕玄：对，这很正常，就像我们（贝联珠贯）招人也不可能这个要求，肯定首先在乎你的研发技能，运维差一点就算了，我们可以有运维团队，但也会陷入这个状况。但我们先期就会让运维更多偏向工具，一开始就是这个定位，同时也慢慢告诉研发，运维不是你的配套，只给你工具和文档，其他是不管的。
+
+极客时间：对小厂来说，有必要制作自己的运维工具吗？现在市面上也有很多工具。
+
+毕玄：但运维的工具很难完全通用，这个比较麻烦。通用的很难满足运维所有的需求，因为运维不像研发比较单纯，他杂活简直多到不可想象。
+
+极客时间：所以只能慢慢转变？
+
+毕玄：只能看各家怎么看待运维。大部分公司其实就没有解法，但新一代的公司可能会慢慢好一点，现在研发在技能层面的要求更完整一点，运维团队也在慢慢转向类Google的SRE，更多提供工具，研究整个系统怎么样做得更加稳定，而不是发布。
+
+极客时间：那运维的职业发展路径呢，你怎么看？
+
+毕玄：架构师。
+
+以前我们跟运维团队说，其实他们最大的出路是成为真正掌控整个系统的最大架构师，因为说实话，架构师其实最好是从运维出来的，研发是出不来的，因为研发没有全貌，但运维是一定有的，他要负责线上，所以他看到的一定是整个系统，知识面一定是超级宽的。
+
+只不过关键是运维你能不能成长为这样的角色，因为架构师最大的问题是研发线认不认可你。研发线会觉得你就一个运维，又没写过代码，你提的方案我觉得不靠谱。所以这就是为什么Google相对好很多，因为他的SRE就是原来的资深研发，研发挑战不了。
+
+研发是一个很难伺候的角色。我后来去研发效能了体会更深，就更难了，研发效能是给研发和运维做工具，这个难度简直高到天了。就像我说的，只要研发觉得自己能干的事都很难。
+
+
+
+　
+
+水友讨论区
+
+对谈到这里就暂时结束了，主要聊的是毕玄从研发转运维的经历。
+
+先说点正经的，运维团队，毕玄认为核心工作是保护整个系统的稳定和成本控制，而运维人最好的出路是架构师，但在当时的阿里，面对运维团队价值模糊的困境，他试图寻找解法，但似乎也看不到希望，迫不得已选择了一条争议巨大的路线。
+
+
+但每个团队确实都要想一下成长空间问题，你自己所在的团队，你觉得现在的空间如何，未来的成长空间可能是什么？能满足你的个人发展需要吗？
+
+
+最后说点不太正经的，今天来个特别的吐槽环节：
+
+
+“我完全可以干，之所以我不干，只是因为我不想干而已”，你的岗位存在鄙视链吗，是什么呢？
+如果你是一线运维，欢迎吐槽当年和研发协作的那些事，当然不能厚此薄彼，如果你是一线研发、测试、安全或其他团队，也欢迎写下你的肺腑之言。
+
+
+毕竟有一位哲人说过，吐槽，是迈向理解的第一步，期待在留言区看到你的精彩发言;)
+
+下一讲我们会接着今天对谈的尾巴继续聊，毕竟毕玄说运维之后，他去了比运维更难做的研发效能团队，会发生什么呢，下一讲见。
+
+拓展阅读
+
+1. 如果你对阿里当时智能化运维的具体细节感兴趣，可以看阿里开发者的这篇：阿里毕玄：智能时代，运维工程师在谈什么？这是当时毕玄做“智能时代的新运维”演讲的整理稿。
+
+2. 在2016 Velocity China 上毕玄也做了一次演讲，主题是阿里应用运维体系演变
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/08基础团队：研发效能部门，解决不了研发效能问题.md

@@ -0,0 +1,281 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            08 基础团队：研发效能部门，解决不了研发效能问题
+                            
+你好，我是叶芊。-
+　-
+上一讲我们聊到毕玄从研发转到运维，对于当时成长空间极其严峻的运维团队，他选择兵行险招，解散掉统一的运维团队，把人还给了所有BU，尝试改变研发乃至集团对运维团队的价值认知，毕竟只要研发觉得自己能干的事，都很难做。-
+　-
+但是运维之后，他又去了更惨的研发效能团队，给研发和运维做工具。-
+　-
+对于这个“难度简直高到天”的新团队，这次他要面对的是什么样的难题？他又是如何发挥自己的长板，分析运维未来的成长空间，找到那几个能体现团队价值的亮点呢？
+
+
+　-
+极客时间：好不容易从运维出来，结果你又去研发效能了？那个时候应该是2016年？
+
+毕玄：对，其实就是运维拆完，我开始带系统软件事业部跟研发效能部。
+
+极客时间：新团队多大？
+
+毕玄：一开始大概三四百人，后面有五六百。
+
+极客时间：你当时带这两个部门的目标是什么？
+
+毕玄：当时安排我去带这两个，系统软件是有明确目标的，就是要做好统一调度，因为行癫上任作为CTO给阿里定的两个最重要的事，一个是统一存储，一个就是统一调度，统一存储就是盘古，统一调度就是我。所以系统软件的成立很清晰。
+
+研发效能是因为之前基础设施的运维，在阿里云、集团各有一个团队，现在最大诉求是整合在一起，做成统一化。至于研发工具侧，没有太多诉求，当然我带团队以后肯定不希望没有任何目标，还是希望能解决研发效能团队的定位问题，这就是第二个目标。
+
+极客时间：定位问题？也是像运维团队一样，研发效能当时的价值没有展现出来吗？
+
+毕玄：对，研发效能是做研发工具的，跟运维一样，大家也会觉得这个团队人很多，都觉得一个研发工具团队200多人？简直太多了，没有一个人觉得你手上人少。
+
+我以前带运维在外围的时候也这么觉得：研发工具团队人怎么那么多，应该给我点人来做工具，给一半就挺好。等我带的时候一看，哇这个团队人也太少了。我带的这俩团队简直了（笑）。
+
+极客时间：研发效能人少的原因是什么？
+
+毕玄：因为研发工具链条特别长。
+
+研发工具你想包括了什么？首先就是代码托管、代码编译，然后需求管理，要做整套需求管理的系统，需求出来了以后你要做项目管理，还要对研发模式做管理，像阿里研发模式不统一有无数种，主干开发、分支开发、敏捷开发……各种都得支持。列举一下你最后就发现，团队里做每一项功能的可能只有俩人，然后就活不下去了。
+
+我说这团队太难带了。因为跟运维一样，大家也会觉得你的价值对公司很有限，但事实上你又必须存在，你盘点觉得自己人很少，但公司觉得很多，其他团队也都认为你人很多，那你就很尴尬了。
+
+极客时间：本质上，人多不尴尬，尴尬的是人多，别人还觉得你没价值。
+
+毕玄：对，因为这个团队除了支持以外，确实很难找到新目标。他原来做的工作就是支持，你研发完对我有什么需求？像编译，以前只支持Java，现在你要C，那团队规模就会越来越大，Google的编译团队就上百人了。所以你看我们人很多，但把功能点全部拆开，类比其他公司，我们根本没人，哪有人？
+
+但是如果你，像运维一样，永远被别人定义成一个支持团队就很惨，你的价值永远得不到大家认可。我们就想尝试改变，因为你不做出改变，人永远不够。
+
+极客时间：所以这个问题，你是怎么办的？
+
+毕玄：我当时带研发效能就在想，短期能不能稍微集中力量做出一两个亮点，只要有一两个亮点就足以证明这个团队对公司的整体研发效能是有价值的，这个团队还是有意义的。
+
+后来我们认为对工具层面的研发效率来讲，代码方向是最好的，就谈了一些人开始做代码搜索、代码智能化，其他地方我们很难解。
+
+　
+
+
+
+　
+
+极客时间：当时你是怎么分析的，可以详细讲讲吗？
+
+毕玄：核心就是想清楚你到底能真正解决研发的什么效率问题。
+
+第一个最大的问题当然是协作效率。但这其实是个研发模式问题。
+
+阿里因为强制统一成一套系统了，所以这套系统压力非常大，一是阿里太复杂了，各业务的状况不一样，有些是创新业务，有些是成熟业务，有些可能是晚期业务，每个都得来不同的。二你想任何一个团队说我觉得现在研发模式不好，想换一个，那你的系统就得支持吧，因为你挑战不了他。
+
+所以我们当时说：想改变这个局面，只有一种可能——研发模式我们比他们还懂，就是对阿里各种不同阶段的业务，你能定义哪个更合适。但说实话这并不容易。
+
+这么多年了，全世界只有某几位顶尖的天才软件工程大师，偶尔提出一两个开发模式，改变了整个业界的协作模式和研发模式，像Linux提出Git彻底颠覆了以前的CVS、SVN，除非能做这种，那你团队影响力绝对第一流。但这太难了，培养出一个大师的可能性不是很大。
+
+而且研发模式很复杂，因为它其实是个协作问题。像敏捷在中国多少年了，包括Google讲代码仓库应该是一个大仓库提高整体的研发效率，但你看中国有多少公司是一个大仓库，阿里也想做，但也很难，理论上Google讲了有A、B、C、D多少好处，我们也觉得Google讲的很有道理，但关键是工程有个落地问题，你有这个想法，怎么走到那？这就是工程。但协作这个工程挑战非常难，我们觉得几乎不可能。
+
+极客时间：所以第一个问题协作效率，短期是不可能了。
+
+毕玄：想解决好协作效率是个长期的活，我们就不纠结了，囤一两个业界挺有名的理论专家尝试看有没有机会提出像敏捷开发、精益开发的思想去影响研发线，让他们接受。
+
+但说实话，我们没抱太大的希望，公司有这么多种类型的业务，要高度抽象出一个很好的协作模式，太难了。到今天为止我觉得这个局面也很难改变，毕竟这相当于你要比他们研发团队还专家。
+
+
+
+
+
+　
+
+极客时间：第一个协作效率短期PASS，第二个是什么？
+
+毕玄：第二个对研发来说以前阿里最影响的效率是什么呢？其实是测试。
+
+测试是个大问题，到现在也是，很多公司尤其服务化以后更严重。因为你原来就一个系统，测试还好，不存在互相干扰，服务化以后好了，有几百上千个系统，那完蛋了，一放到测试环境，你都不知道谁影响了你，所以各家公司就搞出了N套方案，来解决互相干扰的问题。
+
+比如阿里以前先搞了一套测试环境，所有人都在上面放新的代码，但慢慢的大家就发现这环境还是不要用了，没法用，全是异常，你查问题可能发现根本不是你代码的问题，都是别人的，但别人不理你，这就没法搞下去了。
+
+所以，我们又搞了一套日常环境，日常环境是比较稳定的，里面只允许放测试过的正常代码，但因为前面的测试环境不受大家认可，所以大家就时不时在日常环境里跑，然后就又尴尬了（笑），所以日常环境也慢慢。
+
+极客时间：变成测试环境了。
+
+毕玄：对，但一旦变成测试环境就又很乱。
+
+后来希望从中间件的层面去解决，我们把这个叫二套环境，比如在这个环境里，你现在是测试，但别人调用的时候不会调用到你，会调用一个稳定版本。但是中间件要解决，很复杂，因为不光有服务调用，还有消息各种各样的问题。最后我觉得也解的不是很好。
+
+所以阿里后来都已经直接到预发环境去测了，预发其实就是线上生产环境，只不过用户访问不到，但我们内部能访问。因为用的是线上，可以确保如果出问题，应该就是我的问题。但是后来预发环境也乱套了（笑）。
+
+反正为了一个环境问题，尝试了不知道多少年，现在应该还有个团队尝试新的，专注怎么解决环境干扰问题。我们跟很多做研发工具的团队说，如果能解好这个，你们的工具一定很好卖，中大厂这都是核心问题，因为测试效率如果很低，意味着最终上线的周期肯定会被拉长。
+
+
+
+
+
+　
+
+极客时间：前面分析的问题倒是很多，一协作效率开发模式，二测试的干扰问题，但是短期都不好解啊。
+
+毕玄：后来我们就觉得，对研发来讲，我们真正能做的是给他的工具。
+
+你想研发的一天，除了协作这些乱七八糟的事情以外，核心的时间肯定还是花在写代码、编译、打包、测试上，所以我们就在想这4个我们能干啥。测试，前面说了只能看环境问题怎么缓解，解决不大可能。
+
+剩下写代码、编译、打包这三个环节，能不能尽量为你缩短，这就是我们探索的。
+
+编译，我们觉得可以搞一下，像Google Bazel提高编译的速度，我们也投入了一些资源，确实有效果。代码编写方面也是在做的，不管是IDE的改进，还是做代码智能化，重点力量开始投向这些。
+
+其他的，支撑好业务和需求就行，在想不出什么创新的情况下我们也别纠结，就当就是个支持好了。但在这几个地方，我们是有机会做出亮点的。说实话对公司来讲，一个团队，一个这么大的团队，其实有一个亮点就足够了，就可以解读这个团队存在的必要性，最怕的是它一个亮点都没有。
+
+极客时间：判断代码方向是亮点，是因为研发天天用，如果能有效提升的话，作用很大吗？
+
+毕玄：因为代码方向，我们觉得智能化是突破点。
+
+像代码托管就没有突破点，GitHub就是天花板，你最多说我做一个中国的GitHub，等一个机会做备胎；或者你指望Git之后又来了一个新东西，但这需要另外一个天才，Git只是Linus随便玩玩做的东西，这就是天才，你没有。
+
+但代码智能化，即使像阿里的工程师，质量已经是中国中上了，事实上，所有工程师写代码的水平也是有很大差距的，我们希望用工具把代码的平均质量拉高，比如从现在的50分拉到60、70分，对公司来讲就很好了，你说要做到比优秀程序员还好，也不现实。而且这是在阿里，如果做得好，这套工具对外可能会把别人从20直接拉到60，那完全不一样。
+
+这个事，在阿里我们觉得是非常有机会做成的。因为你的代码想智能化，比你自己写得更好，首先你需要有一个优质的代码仓库。
+
+极客时间：代码仓库是需要积累的。
+
+毕玄：阿里绝对具备，因为阿里的大多数代码就是中国中上的优秀工程师写出来的，而且这些代码又是在生产环境运行的，是实际被论证过的。
+
+我们还能捞到这些代码运行的实际数据，就能知道哪些代码其实是更优秀的，比如说这段代码每天被访问了很多次，但消耗的资源很少，而且响应时间很快，那说明写得挺好的。所以我们可以很好地训练AI什么叫优质代码，但这需要一个代码仓库。所以GitHub也在做一个代码智能化的工具Copilot，现在要收费了。
+
+极客时间：GitHub Copilot那个自动补全的？
+
+毕玄：它基于的是大量Public的仓库代码，但这个代码的水平你很难说，当然GitHub有些高水平开源质量不错，但你还是没办法跟有实际生产环境数据论证的比，这是不在一个水平线的。
+
+而且我们觉得阿里还有最后一步，如果实在不行，可以时不时搞全阿里代码Review比赛，选阿里大家公认的几个写代码非常好的人来评审，然后把这些反馈给AI，那这个AI就更加智能了。
+
+所以阿里走通这条路的可能性比多数公司高非常多。当然大公司都有这样的体会，Google、腾讯都一样，因为大家确实是偏中上水准。
+
+极客时间：有多年代码积累，有生产检验，加上AI技术现在也比较成熟，最后实在不行还能加人工评分。
+
+毕玄：对，这如果有机会做好，可以让阿里所有工程师在写代码的时候有自动辅助，你写的时候我就能猜出你下面要写什么，然后给你一段相对优质的代码参考，你只用改一改就可以了。
+
+极客时间：这种工具，研发认可吗？愿意用吗？
+
+毕玄：研发对这些接受度很高，你能帮我写得更快还写得更好，那好的。所以GitHub Copilot要收费了，我在很多程序员群里看到都是愿意付费支持的。而且说实话我觉得他做的也没有那么好，离我们当时想象的那个代码智能化工具还有差距。
+
+很多协作工具像office、飞书等等为什么受欢迎？是因为能提高我协作的效率，对研发也一样，如果有个东西能提高我写代码效率，我愿意付钱的，个人都行，都不需要公司。其实IDE 不就是这样子，以前很多人觉得我用记事本写代码很牛，我们说那是傻，工具能极大提高你的效率，干嘛不用呢？那不是傻吗？所以IDE 每年能收这么多钱，你问工程师IDE 到底有什么好？就是因为它能让我们写代码的效率更高。工具就是这样。
+
+极客时间：所以研发效能部的目标终于很清晰了，短期重点代码智能化做亮点，长期做研发模式、测试环境干扰。当时你们做到什么程度呢？
+
+毕玄：我们就做了一年多，因为一两年之后我就不带这个团队了，但现在这个团队应该还在，阿里前段时间好像对外发了一个代码智能化的开放工具（云效Codeup）。
+
+
+
+
+
+　
+
+极客时间：亮点仔细分析了，也做了很多工作，你觉得研发效能的团队价值有明显提高吗？
+
+毕玄：还是很难，因为研发效能这个东西很难被衡量。
+
+大家常见的是衡量研发对需求的实现速度。比如一个需求过来原来是一周，你现在变成两天，但这里有个问题，需求的粒度是什么？运维或者产品提一个需求过来，你很难拿什么东西去衡量这个需求的粒度，最后到了研发这边其实就没法衡量。这是个非标。
+
+极客时间：大家没有公认的大概指标吗？
+
+毕玄：没有，我觉得只有一些小点。比如说大家公认Google的编译做得非常好，就Bazel，但这并不代表研发效率。研发效率是个综合话题。
+
+而且像我们投入很多去做代码，你觉得自己做了一个特别牛的、在全球都很领先的工具，但对研发来讲，没用，对于研发侧来讲，他们认为我效率的核心不在这，阿里的研发抱怨最多的、最影响他效率的是什么？是前面的环节。所以这种团队很尴尬。
+
+极客时间：抱怨最多的，是前面的需求搞不清？
+
+毕玄：对，是需求和协作，这环节你说你能帮他啥？研发说我最大的问题是一天能写代码的时间很少，大部分时间在开会。但我说这是管理问题。
+
+你想为什么一家创业公司研发很快？以前淘宝也很快，上午提需求，下午就上线了，为什么？因为以前根本不需要评审，也不需要各种环节，你过来说一下，我立刻就开始写代码。现在怎么可能？现在你一个需求提过来，背后可能涉及十个团队，那这十个团队我得先讨论一下吧，还得排个期吧，开会就已经好几天了，这还做个啥？两周做完一个需求就不错了。
+
+极客时间：所以总的来看研发效能，没做出东西很尴尬，做出了东西还是挺无力的，这怎么办？
+
+毕玄：就看团队定位了，如果对公司来说，能接受这个团队在某些点上能做到全球TOP，不需要我们去论证自己做出来的东西的价值，那这个团队的存在空间就有了。
+
+像美国很多公司都认为工具才是核心，不需要说来论证一下你为什么做了这个工具？你效率提高了多少？他们信仰，只要工具做好了，效率就提高了。我以前拜访Facebook，他们的工具团队很受重视，大家都很向往，觉得他们简直太牛了，因为他觉得我用的都是你们团队做的东西。
+
+但中美在软件这一侧的信仰差别是很大的。美国可能因为人太贵了，所以他们一开始就特别相信工具，中国相对来讲人的成本低一些，所以一开始中国不觉得工具有多重要，我就是堆人。只有等到两种情况：一发现堆人也解决不了问题，二开始感受到堆人的成本，只有到这两个阶段才会觉得那我们得做好工具。
+
+但这个时候他对工具的期望太大了，所以这个工具团队很难做，因为工具并不能真的彻底解决问题，如果能彻底解决，那也太简单。因为很可能这个团队解的是研发效率里最小的那个环节，最大的环节根本是公司层面的问题。
+
+极客时间：美国是很向往工具团队，但中国是你们作为保姆团队该给我支持？
+
+毕玄：而且还都觉得你们做的太烂了。研发就是那句话，只是我没空自己干，否则我一定能比写得你更好，高层，你又很难向他证明为什么工具很重要。
+
+office的故事本来我们觉得可以一直讲，你说office重要吗？Office当然重要，所以你愿意付费，那为什么研发工具你不愿意？office你有论证过吗？你也没有，但你就是相信了。相信真的很重要。
+
+海外对开源到商业也是信仰，他相信你开源做好了，接下来的商业化一定能做好。但在中国这个是要被论证的，但论证很难，它就变成了一个悖论。
+
+中国像ToC不也是这样，最早ToC能吸引大量的免费用户，但你也要论证，你吸引了这么多免费用户为什么最终你能赚钱？其实没有证明，所以淘宝最早被无数人质疑，你每年亏这么多钱，到底能不能盈利？这就必须感谢雅虎。
+
+极客时间：广告模式？
+
+毕玄：对，雅虎成功创造了互联网广告模式，直接把免费流量转移成羊毛出在猪身上，所以后来做ToC的人就不用证明能不能盈利这个事，只要你能做到用户量很高，大家就觉得你一定能赚钱，当然也不一定，就像共享单车，用户量做得很高，最后还是没有盈利。但是他一开始是不用解读的，这就是相信。
+
+这在软件上很明显，国外就相信了，但在中国要面临很大挑战，所以中国各家做工具的团队都过得不是很好。
+
+　
+
+
+
+　
+
+极客时间：近几年，业界特别重视提研发效能，这种关注度是不是也是分阶段的？
+
+毕玄：对，大公司肯定会提的，研发效能每年确实是被提的核心话题。
+
+极客时间：去年好像提的更多一点，是因为疫情吗？
+
+毕玄：没有，我觉得都会提。
+
+为什么大厂现在总提研发效能，因为大厂到了后面人效比是下降的，所以只要过了那个点，很多公司都会提，因为他每年都会觉得我业务增长是这样，但你研发人员怎么还在不断增长，他当然觉得有问题，加上研发又比较贵，成本比较高，他就会说你们研发的效能得提高啊。
+
+但关键是研发效率到底怎么提高？大家就指望那个研发效能团队，但其实那个团队根本就承担不了这活，他承担的只是很小的一部分，最大的部分实际是管理问题。
+
+极客时间：或者说因为到了现在这个阶段，其实很多公司都找不到更好的方式去盈利了？
+
+毕玄：研发砍十个人公司搞不好盈利了，阿里砍掉这一轮，可能这个季度的利润都要增加一些，因为研发太贵。
+
+所以要说起来，他们不应该老挑战研发效能，想快的，还不如把产品线砍掉一半，研发效能立刻就提高了，因为无效需求太多了，只要产品经理够多，研发就永远不够，毕竟产品经理只要人在，他就会想需求。
+
+极客时间：既然经过这么久的实践检验，为什么大家还是会对研发效能关注这么高？
+
+毕玄：因为大家还是幻想能有一个解决方案。毕竟一旦解决好了，必须说对公司的帮助无比巨大。
+
+极客时间：那你怎么看，你对这个团队是抱有信心的？
+
+毕玄：对，我认为如果你能做一个工具，让研发很喜欢，其实就可以，至于对公司的价值，就看团队的人自己怎么看。
+
+说实话，我觉得即使团队在代码层面做得多好，可能在研发团队能得到比较好的口碑，但公司也不会觉得你解决了研发效率的问题，因为公司层面只看最后的人员增长，就很复杂。
+
+所以我跟他们讲，研发效率是个综合过程，你不能做的，再怎么叽歪也没用，但我们能做的，那就尽可能做好呗。如果你能做到世界顶流，就算不能在公司被认可，但你在圈子里是会被认可的，就像Google做Bazel的团队，你以后的职业生涯是没有问题的，如果在这家公司身上获取不到，在另外一家公司身上也会获取到。那就别纠结了，关键纠结也没啥用。
+
+　
+
+水友讨论区
+
+今天的对谈到这里就暂时结束了，毕玄担任研发效能部Leader的这段经历，确实让我感受到了为什么很多人会评价他对方向的判断非常好。
+
+我们先简单复习一下。首先，出发点是对公司来讲，一个团队需要有一个亮点，才能解读这个团队存在的必要性。那对研发效能部门来说，他们平时做的事是给研发提供支持、做研发工具，如何找到亮点呢？
+
+毕玄分析核心就是想清楚这个部门到底能解决研发的什么效率问题，一个研发，一天的时间花在协作、写代码、编译、打包、测试上，于是拆解下去有了这么几个方向：协作效率、测试的干扰、代码智能化工具、编译工具等，再针对每一个方向思考可行性和见效周期。
+
+虽然最后非常现实，也没能有效提高团队在集团的地位，但毕竟尝试有了效果，后面可能就是时间问题了。
+
+
+回顾自己呆过的团队，你觉得有清晰的亮点吗？参考毕玄的分析思路，你认为自己团队短期可以发力的亮点是什么呢？
+工具，被公司寄托厚望却又很难被认可价值，你在工具团队做过吗？有遇到什么尴尬又难解的问题吗？
+
+
+欢迎在留言区分享你的思考和故事。如果有其他感兴趣的话题，记得留言。
+
+下一讲我们会聊一聊毕玄做统一调度的故事，下一讲见。
+
+拓展阅读
+
+1. 如果你对测试环境的难题感兴趣，可以看阿里开发者的这篇：在阿里，我们如何管理测试环境？
+
+2. 关于工具的作用，毕玄之前写过一篇小短文：程序员的生产力工具
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/09统一调度：只是问题非常多而已，摔出来就行了.md

@@ -0,0 +1,273 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            09 统一调度：只是问题非常多而已，摔出来就行了
+                            
+你好，我是叶芊。-
+　-
+上节课我们聊到16年毕玄拆完运维去带系统软件事业部跟研发效能部的经历。-
+　-
+对于高层根本不感兴趣的研发效能团队，定位是个大问题，做了一通现状分析之后，他终于找到了清晰的发力点：短期做代码智能化，长期解研发模式和环境干扰。-
+　-
+对于另一个团队——系统软件部，虽然高层给了明确目标，但他说做的也很不顺利，最后能做成也很难讲，可能时机比较巧。-
+　-
+作为自己在阿里14年的第三大亮点，统一调度的成功居然归因于“时机”？为什么？让我们跟着亲历这个集团级项目的总架构师，看一看当时有哪些障碍？他又是怎么处理的？
+
+
+　-
+极客时间：你当时带两个团队，研发效能之外就是统一调度，这个部门的目标是什么？
+
+毕玄：本质也是成本，阿里内部以前有好几套调度系统，这次想做成一套统一的，我们叫Sigma，向Borg的下一代Omega致敬。
+
+调度我们做了很多年，2011年做容器化T4就是，核心目标就是为了控制成本，当时我们做了两三年，大概知道了在这方面Google的Borg做得非常好。
+
+那个时候传闻Google认为自己的核心竞争力是什么？最早他就做搜索，他认为自己最重要的竞争力是，一我排序结果的准确度比多数公司好；二做同样的效果我付出的成本是你们的1/10。这确实是，成本如果差这么远，商业上就没办法做下去了，这里面，Google觉得调度系统Borg承担了很大角色，类似它的Page Rank算法，是整体竞争力的一部分。
+
+所以外部很少有Borg的信息，保密性做得非常好。后来我们知道一点是，2015年Google发表Borg论文，那其实几年前就写好了，只是内部一直摁着不让发，觉得可能对业务的核心竞争力有影响。
+
+极客时间：所以13年你们了解到的信息是什么，可以具体说下吗？
+
+毕玄：就是个思路。我们知道了以后都觉得哇这个思路简直太完美了，其实大家都能想到，但我们需要有人给信心，因为这个思路大家都觉得太难。
+
+是这样，因为多数公司的机器会分成很多个池子，最典型的是一个机器池子用来跑在线业务，另外一个用来做大数据的业务。
+
+大数据这个软件的核心设计思想就是尽量并行化，把一台机器的资源全部吃光，所以大数据特别吃资源，能把池子用得特别满。而在线业务，不是不想吃资源，它必须考虑的是什么？是稳定性，如果出问题了，我最好要有足够的冗余，加上一天还有很多不确定的高峰，所以我机器的余量一定是为高峰准备的，利用率就没有办法很高。
+
+极客时间：在线的机器量，可以根据高低峰来伸缩吗？
+
+毕玄：但事实上这是一个悖论。因为对在线来讲，稳定性是最重要的，如果你不断伸缩，万一出问题了，可能得不偿失。很多高峰是无法预测的，即使是淘宝看起来都是做大促才有高峰，但如果有个社会热点，除了微博，淘宝也会受影响，以前比如谁出了名，有了件衣服同款，那立刻爆。这种事情是没有办法预测的。
+
+除非你可以做到秒级以下的伸缩，那可以。我后来带调度，也给了人去探索这个方向，但必须说真的很难，至少目前我们觉得从技术上来讲很难突破，伸缩的风险不那么可控。
+
+极客时间：所以一方面是大数据机器用满，一方面是在线空闲，在线也不好伸缩。
+
+毕玄：很多公司到了一定规模，在线机器增长其实还好，因为在线跟业务基本成正比，就是QPS，比如说现在100，明年你希望做到200，那我就加机器；同时，因为每年的机器比上一年更好，所以从预算角度来讲，公司觉得是合理的，业务增长20%，你机器增长比如15%，那当然可以，至少没多出钱，能接受。
+
+但大数据就有问题了。通常大数据机器只要开始用了，每年的增速会越来越快，因为存储量一直在那，而大家想采集的数据细节会越来越多，这样才能更精准地画出特征，所以大数据的机器就会多；另外公司的经营一定会越来越难，以前增长比较容易获得，可以粗放式，但后面你肯定要精细化，但精细化对大数据的要求又越来越高，所以机器会越来越多。
+
+这个时候，技术层面大家都很容易想到一个方案：既然在线这边这么混，大数据这么满，能不能合在一起，让大数据用在线？这就是当时Borg给大家的核心思路。
+
+极客时间：把在线和离线混部？
+
+毕玄：对，但其实Borg自己压根就不是这样，它诞生的时候就认为这两个本来应该在一起，我们以为一组机器跑大数据，一组机器跑在线，它一开始就认为干嘛要分？所以这就是Google。
+
+极客时间：理念先进，都是机器，我只是时而跑离线时而跑在线。
+
+毕玄：你说对了，Google觉得反正我机器在这儿了，该跑啥就跑啥，哪有说这个机器只能用来跑这个，没有。
+
+Google当年有一个高管跳槽到百度，他第一次看预算的时候发现还分大数据机器和在线机器就很疑惑，为什么还要分机器类型？他说我们从来不分。所以百度后来做了Matrix，拿了两次一百万美金的百度最高奖。其实百度Matrix的思路就来源于Google。
+
+
+
+
+
+　
+
+极客时间：在离线混部，这个思路倒很直白。
+
+毕玄：这个思路大家确实也能想到，也都觉得应该这么干，很多人就会问了：为什么不这么干？那肯定是有原因的。
+
+从技术上讲，大数据跑到在线确实有很多问题。首先机器以前是分开的，最典型的就是通常在线机器是1块盘，大数据机器是12块盘，因为它跑的时候需要算非常大的数据，但在线以前数据量非常小，大数据上去跑的时候，存储不够，大家觉得没法搞。
+
+另外物理的基础设施条件也有要求。
+
+第一在线机器和大数据机器要在同一个城市。比如从A到B的网络我们叫城际带宽，如果不在同一个地方，意味着要走这个，但城际的网络带宽非常贵，你如果跑大数据就更不得了，要求非常高，这条路是不可能的，所以首先要的是大数据和在线搬到同一个机房。
+
+而且当时物理基础设施除了机房，还有网络的问题，以前我们的网络是千兆，对大数据来讲不够用的，它需要万兆以及更高。千兆就要搞各种限制，所以也很痛苦。我们2014年只能在上海机房搞个小的试验环境，去做一些试验。
+
+除了基础设施，还有干扰的问题，因为大数据任务会吃光所有的资源，如果你在线也同时跑，会不会影响到在线业务的稳定性？如果被干扰了，导致你的响应时间下去了，就完蛋了，在线业务会不惜一切代价保稳定性，你想如果业务都挂了，省钱有什么意义，对不对？
+
+极客时间：以前机房分开也是出于成本考虑吧？
+
+毕玄：对中国西部城市比如说内蒙古，电非常充足，电费非常便宜，加上温度通常比较低，建机房就很好，很省钱。但问题是互联网的出口通常又在一线城市比如北京、上海这几个点，做在线业务是需要互联网出口的，我必须在这些城市或者附近。
+
+这就奠定了以前大数据、在线都在不同机房，所以Google这个思路一开始在中国就做不了。当时我们面临的第一个挑战就是这个，怎么说服高层阿里建一个大机房，让在线和离线搬到同一个地方去？
+
+但这对任何一家公司都是一个非常大的决定。建一个大机房是几十亿的投入，要找到一个地方电费便宜，也要在互联网出口附近，也要探讨清楚ROI到底是什么？因为开始肯定要增加投入，以前没有这些，现在砸好多钱，你到底能不能省回来？这就是又是那个论证问题。
+
+极客时间：所以机房问题，团队也没办法，只能等公司决策？
+
+毕玄：那没办法。现在阿里是建在张北、南通等几个地方，但你看这几个地方显然都不是大城市，但离大城市又不远，既享受到了电费、气候，又享受到了互联网出口，这就是非常好的选择。百度最早在阳泉也是，建了一个30万台机器的大机房，然后是阿里15年建的张北，腾讯也开始，后来思路就全部统一了。
+
+极客时间：后来阿里建了大机房，是因为说服了高层？还是看别人做了？
+
+毕玄：那倒不是，阿里有很多原因，主要是因为云起来了，对我们来讲小机房效率不是很好。所以后来统一调度能做，也很难讲，可能是时机比较巧。
+
+反正后期走这个方向的公司都很痛苦，因为你前期物理设施不是按照这个来的。像Google是一开始就是这么来的，所以它不存在这些问题。我们后走这条路的都很尴尬。
+
+　
+
+
+
+　
+
+极客时间：在离线混部这么多问题，当时感觉都没有解法，你们做的时候有信心吗？具体进展是怎么样的？
+
+毕玄：信心是有的，因为统一调度说实话跟做异地多活不一样。
+
+这次有参考对象，只是资料不公开而已，但大思路在，所以你的大方向是有的，异地多活是没有大方向的，纯靠自己摸索，完全不知道能不能走通，很可能会走挂，但调度，我们觉得Google能干成，至少这条路走下去应该没问题，不会走不通，只是要解决的问题肯定非常多而已。
+
+但在阿里，必须说我们做这件事情难度比百度更大。百度是高层Push大家这样做，而且大数据团队有很强的动力，在阿里，我们有很强的动力，但我们是在线业务团队，不是大数据团队，这个事想做成，很多工作是要大数据团队做的，当年他们还有别的很多事情要干，觉得这不是我的重点。
+
+所以各种原因，尽管我们从14年开始做，但进展一直比较慢。
+
+物理上的限制，是等15年建大机房了才有可能性了，然后网络要升级到万兆，上面升级到25G，40G，100G，到了16、17年那个时候网络都具备了，也没有问题。剩下要解的核心问题就是大数据对在线的干扰，还有两边机器的磁盘不一样。
+
+极客时间：磁盘问题，后来网络好了是不是就解决了？
+
+毕玄：网络升级上去之后我们可以走计算-存储分离。
+
+但计算-存储分离内部当年也争论非常大。原因是大数据软件在一开始的核心设计思想，除了高度并行、充分使用资源，还有一个是“存储和计算一体化”，就是调度的时候会尽量让任务和存储在同一台机器上，这样算起来最快。但你现在告诉大数据团队不要放在一台机器上，这其实挑战了大数据的很多思想。
+
+所以内部争论非常巨大，但我们反正可以逼着你必须走这条路，比如说卡预算各种。
+
+极客时间：跟以前异地多活一样不给你分机器？
+
+毕玄：对，因为我所有机器是没有磁盘的，你必须走分离，否则我在线给你机器你也跑不了。
+
+所以基本等16年阿里开始大力提统一调度，也有了正规军，很多问题才慢慢被解决，一是物理条件具备了，其实是18年才具备的，但大家在16年开始探讨，觉得这个方向可行，基础设施就去配套准备，所以大机房、网络都在那两年完成了。
+
+极客时间：到16年那个时候，对在离线混部方案的价值，大家的认知也统一了？
+
+毕玄：我觉得很大的原因是预算上大数据对成本的压力已经非常大了，必须要控制。
+
+但控制的思路我们探讨了很久，觉得最好最完美的仍然是Google。你想，在线有一大堆机器在手上，如果能把大数据跑上去，相当于不用花钱的，大家拍脑袋想都觉得能省好多钱，是个好方向。
+
+极客时间：现在就剩下干扰问题。
+
+毕玄：对，就是阿里的操作系统团队。系统软件部在我一开始组建的时候，操作系统团队可能只有10个人左右，人很少，然后到2018年的时候大概有100人，主要就是为了解决干扰问题。
+
+极客时间：你们当时遇到了哪些问题，业界有参考吗？
+
+毕玄：Google尽管在论文里提及一两句，但不会讲更多细节，他论文的风格一般是这样，只是告诉你我很牛，但要怎么做到这么牛不会讲。你只能自己实践。
+
+我们就必须靠大量人力去堆，在这个过程中肯定会出问题，但只要出了问题以后我有专业的人，可以把问题迅速解决掉就能做。所以我们其实是这样摔出来的，也没有什么。
+
+这因为一方面公司信任，另外一方面是我们的在线业务有回滚、容灾各种策略，也有异地多活可以切流量，相对来讲是在比较安全的情况下做尝试，所以我们也不太在乎，出问题了就把流量切走。
+
+
+
+
+
+　
+
+极客时间：你们当时尝试的结果怎么样？
+
+毕玄：从2016年到2018年，我们大概跑到了1万台机器，相当于在线有1万台可以给离线用，那一年离线少采购了5000多台机器，1台假设10万，所以一年省了5个亿。
+
+关键是不光这一年，下一年我只要继续扩大在线规模，就能继续省钱，到后面每年省的钱会越来越多，因为技术已经是成熟可以被复用的了。方案上、技术层面上肯定不会有太大问题，剩下全是工程，工程是很缓慢的，你就算技术走通了，工程要完全落地也要个周期。
+
+这可以用一个指标直接体现，公司所有服务器全天的平均利用率，像Google就只看这个指标。大部分公司应该都小于10%，阿里16年开始做的时候是8%，Google发表论文的时候利用率大概是50%，这意味着Google只用1/5的机器就可以做同样的业务，离它讲的核心竞争力非常接近。
+
+极客时间：为什么业界、阿里和Google差距这么大？
+
+毕玄：中国公司更难是因为我们不是全球化的，大数据是很高，但晚上没有流量在线就是零，所以你平均一下就完蛋了，利用率就很低，但国外很多公司会好一点。
+
+以前我们问Facebook这个问题，因为Facebook没有学Google走统一调度。我们问为什么？Facebook说因为我的在线业务全天流量都还挺高的，因为它是一个国际化的网站，全时区覆盖。那我们没有，中国公司这一点确实是个问题。
+
+极客时间：所以从那之后，利用率就成团队重点关注的指标了？
+
+毕玄：阿里每年就在不断地推进利用率指标，我们甚至讲到连财务都理解了，财务挑战研发线的服务器成本，他不关注其他，只看利用率要拉上去。
+
+以前，研发的服务器投入，财务线的人是没有方法挑战的。你说要采购100台，财务说太多了，你说业务有多少需求、量多大，所以需要采购，然后财务听完晕倒了，他没有办法反驳你，因为你是拿业务在说事。但后来我们的财务就说看看你们利用率才多少，为什么要采购？不给批。我们训练了他们怎么挑战研发，就很好，连我们CFO都懂。
+
+极客时间：利用率，阿里现在做到多少了？
+
+毕玄：我是2019年初不带这个团队了，当时从原来的小于10%做到了20%左右，相当于翻倍了，就意味着成本有可能减半。
+
+Google这两年据说已经推到了60%，我们以前认为50%是天花板，不可能再多。以前财务也问，你们说利用率可以低，但得告诉我多少是合理的。我们总不能说小于10%是合理的，这解释不过去，从技术上也得编个理由，但50%我们说是可以解读的。
+
+一是因为这是全天的平均，如果说50%，意味着高峰肯定会比较高，平均一下已经很少了。第二是多数CPU的设计原理都是超线程，你看到两个核，物理上只有一个核，只是说软件层面具备跑出类似两个核的能力，但其实是不可能跑得出来的。所以我们说就打个折，当然这有点忽悠，但财务线非IT的人可以理解，觉得比较有道理（笑）。
+
+极客时间：但是现在Google推到60%，这套解释又说不过去了（笑）。
+
+毕玄：没想到Google竟然又突破了，做到60%左右还是很稳定，所以我们觉得它就是天花板了。
+
+现在阿里这个团队还在做，去年做到了30%左右，天花板是60%，阿里规模这么大，我们假设50%是天花板，那30-50%也还有很大空间值得努力，ROI还是非常高的，所以这个团队一直评价都非常好。
+
+　
+
+
+
+　-
+极客时间：调度系统Sigma，你们当时做的挺早的，看报道K8s生态起来了之后，你们就把Sigma的技术栈换到上K8s了？
+
+毕玄：那是后来，我们2016年做的时候，Docker最火，K8s还没起来。当时在调度上的竞争非常激烈，因为调度其实会把下面的容器屏蔽掉，Docker觉得如果自己不往上做调度很危险，就开始做Swarm，然后Mesos是另外一家，Google刚把K8s开源出来。
+
+而且Google以前也不做开源，他的套路是发论文然后什么都不干，但他在大数据上的伤害比较大，之前他发了MapReduce那几篇三驾马车的论文，发现自己啥也没得到，然后什么Hadoop公司全起来了。
+
+关键是后来他做云，云上放MapReduce，但所有开发者用的接口全部是Hadoop接口，导致Google不得不去兼容Hadoop接口，简直太搞笑了。他们内部觉得我MapReduce做的比Hadoop好太多了，我是个成熟的很牛的东西，你们竟然不用。
+
+那之后Google才发现重要的不是发论文，是做开源抢占开发者，所以在K8s上，Google吸取了教训，开始对新套路有点概念了，我先发论文占领影响力，然后再发一个论文实现的开源产品。但Google不擅长做开源，就找了擅长开源圈子玩法的RedHat，联合起来做K8s，因为Borg跟内部很多系统搅在一起，没办法开源，只能重做。
+
+极客时间：那16年你们刚做的时候，技术怎么选的型？
+
+毕玄：我们当时选择了Swarm做Sigma，但2018年的时候K8s就基本垄断了，我们很多的业务方用的是K8s的API，访问Sigma就不通，导致我们必须兼容K8s的API。
+
+但在兼容上面，我们在很多开源路线上都犯过错误，一开始其实有一个开源的东西，但是我们先自研，然后等开源的那个拥有了最多的用户，我们就不断兼容，但是你兼容会越来越痛苦，因为开源一旦起来以后是一个很健康的社群，有非常多公司的合作，会越做越好，到了那个阶段你是抗衡不了社区的。
+
+所以兼容这条路其实是走不下去的，我们就决定不做兼容，把Sigma扔掉，基于K8s把Sigma做的有些东西放到里面去，就是ASI。
+
+极客时间：兼容的痛苦是指什么？
+
+毕玄：因为社区的关键问题是控制不住，我们当年经历过很多次这个过程。
+
+比如说一开始对我来讲这个阶段非常重要的需求，对他来讲可能一点都不重要，那我们肯定觉得开源做的不好，需求又很急，我们就大量自研做了很多Patch的东西。但后面发现开源一旦起来节奏太快，它增加了很多东西，其实覆盖掉了以前我们做的很多改进，这个时候就很尴尬了，到底是升级成它？还是保留自己？我们后来觉得应该尽快升级成开源，因为会被它拉得越来越大。
+
+极客时间：所以Sigma的事大家都能接受？当年大家也不太能预料到K8s会迅速起来，所以后来Sigma换到K8s上是比较必然的事？
+
+毕玄：大家能理解也能接受。确实肯定有些人会很不舍，毕竟做了几年，而且业务效果也在，最后不得不扔掉。
+
+但这确实是我们当年判断的失误，如果更早选择K8s会更好。但16年的时候我们看Swarm和Mesos，加上K8s不成熟，不觉得开源有绝对优势，觉得自研有优势有机会。
+
+所以我们后来反思，做技术选型的时候，如果开源界已经有一个很成功的东西，自己又没有什么很颠覆性的思想，还是拥抱开源比较好，没必要挑战。阿里在开源这条路上吃过很多亏，因为以前都自研，HSF和Dubbo也是典型。
+
+极客时间：HSF和Dubbo是指什么，可以具体讲下吗？
+
+毕玄：HSF是我们自研的产品，Dubbo是开源的，在整个开发者群体里肯定有最多用户。但阿里收购完一家公司会告诉他，你把Dubbo换了，换成HSF。
+
+很多公司觉得很尴尬，你们进来之后，业务啥也没干，先把技术换掉了，阿里以前经常这么做。我们后来说像这种，就不应该让别人换掉，应该把我们自己换掉，所以HSF后来新版本的目标就是换成以Dubbo为核心，支持内部HSF协议的解析，这样以后收购就非常简单。
+
+极客时间：我们现在站在事后看，当时你们判断开源不成熟，选择自研Sigma，是不是因为大厂不可能说等两年，等开源成熟？
+
+毕玄：不可能等，而且大厂确实挑战也比较大，要解决的问题很多，所以如果开源如果不是很成熟，很难说我一开始就选择开源。
+
+极客时间：但一个领域，开源如果已经成熟了，大厂才开始用，是不是说明你们没有更前瞻地看到这个领域的问题？
+
+毕玄：大厂很有可能比开源看到更快，所以确实就是你说的很尴尬，现在大厂的自研走上了一条很尴尬的路线。
+
+开源反噬自研是之后业界的长期话题，以前很多公司都是自研，但现在开源已经被玩得太多了，什么都开源，那之前的自研到底怎么办。
+
+反正我们的判断就是，如果开源的东西已经是主流了，比如说像Spring cloud，那没必要做一个新东西再去跟它竞争，因为我们也只能靠开源去争，但如果没有革命性进步，关键也竞争不过他，所以我们后来做了Spring Cloud Alibaba，就是觉得我竞争不过你，跟你一起玩好了。策略就是这样，总体还是拥抱开源，因为你要么就自己做个开源，要么就用开源做，就这两条路。
+
+
+
+　
+
+水友讨论区
+
+今天的对谈到这里就暂时结束了，重点聊毕玄当年做统一调度的经历。
+
+虽然这些年毕玄换了不少领域，但从他对成本的关注这条线讲，之前做的所有事情又能大概串联起来，最早做的容器T4，到后来的异地多活，到今天的统一调度，后面他创业选择的方向也是做企业的云成本控制FinOps。这么看，成本可能是一个企业始终关注的话题。
+
+
+Google当年分析自己的优势也提到这一点，一是排序结果的准确度比多数公司好，二做同样的效果付出的成本是其他人的1/10。分析自己所在的团队/公司，你觉得优势是什么呢？
+关于统一调度的技术选型，我们也聊到了开源和自研的问题，毕玄的反思是“如果开源界已经有一个很成功的东西，自己又没有什么很颠覆性的思想，还是拥抱开源比较好。”你是怎么看的呢？
+
+
+如果你有更感兴趣的话题，欢迎在评论区留言，如果觉得有启发也欢迎分享给身边的朋友，一起讨论。
+
+读到这一讲，时间线已经走到了2018年，毕玄马上就要从阿里离开了，下一讲我们聊聊这个话题。下一讲见。
+
+拓展阅读
+
+如果你对统一调度的具体技术细节感兴趣，可以看这几篇：-
+阿里云云原生写的揭开阿里巴巴复杂任务资源混合调度技术面纱-
+阿里巴巴中间件写的：给 K8s 装上大数据调度引擎：伏羲架构升级 K8s 统一调度-
+云技术的新变革：阿里云13年后重构全部核心调度系统
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/10出走大厂：离职？还是不离职？这是一个问题.md

@@ -0,0 +1,257 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            10 出走大厂：离职？还是不离职？这是一个问题
+                            
+你好，我是叶芊。-
+　-
+统一调度做完，时间来到了2018年。当时有这样一份报道：“2018 年的 12 月，CTO 行癫调任阿里云总裁，宣布阿里全面上云，组建了以毕玄为上云总架构师的架构组，确定了上云的方案和步骤。”-
+　-
+从外部视角看，我们很容易推测好像毕玄又被委以重任了，但在当时他却有了离职的想法，那之后一年多就走了，当时到底发生了什么？-
+　-
+我们继续对谈，聊一聊他离职的故事，以及对自己阿里14年的总结。
+
+
+　-
+极客时间：看你的经历，统一调度做完，你就去做集团上云的项目了？
+
+毕玄：当时18年年底有个组织调整，行癫宣布上云，让我兼集团上云的架构师，但我也没有做太多，集团上云说实话早就奠定了基础，我只是定调的，就什么叫集团上云。
+
+腾讯那篇文章很像我们当时上云，把里面的公司名改一下就是阿里，一模一样，说明两家公司对上云这个事情，内部争论都是存在的。因为什么是上云？行癫是不会说的这么清楚，行癫只会说你们2年搞定，我对外说完了，剩下你们做不做得到，那就是你们的事了。
+
+但没有人知道做到什么程度叫做上云，有100种方式解读，可以解读得很简单，也可以解读得非常难，我当时还是定了一个比较有挑战的目标。
+
+极客时间：上云会分业务吗？
+
+毕玄：不分业务，肯定是先上核心。阿里后来做所有重大技术变革都是先做核心业务，然后再做边缘。
+
+极客时间：但一般不是会用边缘业务先试吗？
+
+毕玄：我知道，但你先做边缘并不代表任何东西，因为核心不会觉得你上了边缘就解决了它的问题，它还是没有信心，但是如果你先上了核心业务，边缘会认为我也没问题，后面工程收尾就变得非常简单。这是阿里后来的调整，最早我们也是先做边缘，但发现那样工程周期更长，而且很难，但一上来就搞核心，后面其实很简单。
+
+
+
+极客时间：后来你有段时间去带视频云团队了，那是怎么回事？你之前好像完全没有视频方向的经历。
+
+毕玄：上云做完19年的时候我准备离开，其实18年我就想走了，因为一些汇报线上的问题，但公司各种谈，反正折腾了很久，19年年底刚好疫情，过年的时候行癫说要么你去带视频，他还是比较懂我的，知道我想做的是偏基础技术的东西，加上离职也离得不是很顺利，我就去了，一直带到21年8月离职。
+
+我是一方面希望在技术上拓展一点，另外视频是阿里云一条不算小的产品线，在商业上更有要求，所以我觉得也挺好，可以去看看偏商业的业务是什么情况。可能我运气也相对好一点，2021年刚好是音视频在云赛道最火的一年，声网、Zoom都到天上了，声网市值100多亿美金，Zoom 1000多亿美金。
+
+极客时间：那在视频云团队，你负责的什么？
+
+毕玄：当时技术我几乎是不管的，我带产品、销售和运营，全是业务团队，拜访了很多外面的各种客户。现在想想也不是坏事，算是一个积累，我对商业有了更多感受。
+
+我发现商业是完全不一样的。商业不是说你做得多好就一定会成功，可能要看很多业务策略的东西，但业务策略就跟技术完全不一样，更模糊。技术，你觉得这个方向可以，解决技术问题就好，但业务，你觉得这个方向可以，有很多内外部因素会影响，很多问题也不一定能解决。
+
+　
+
+
+
+　-
+极客时间：如果总结一下自己在阿里的14年，你觉得最骄傲的事是什么？
+
+毕玄：还是那三个，从来没有变化，HSF、异地多活和阿里的统一资源调度。
+
+极客时间：最遗憾的事呢？
+
+毕玄：没啥遗憾，挺好的，阿里这一段我是真正在搞技术，专业性、深度、广度都得到了很好的提升，而且我们这拨人也跟着得到了很好的回报，这也很重要。
+
+但说实话这就是幸运，我们这波做基础技术的人，从2007年到2021年，刚好是阿里最高速发展的一段时间，业务高速发展就带来了很多技术上的问题，总要有人去解，所以阿里给了很多人机会。
+
+因为换一波人其实也一样能做好，工程师最擅长解决问题，在阿里，问题已经展现出来了，你只要去解决就可以，这对大多数工程师来讲都不是难题。如果你不在或者在另一类的公司就不可能，不是说你有没有能力的问题，没有平台，你有能力也没用。当然现在有点变化，因为中国技术创业的环境好了很多，以前是一点机会都没有，现在应该有那么一点。
+
+极客时间：像之前讲的淘宝消防队，在外面很难知道问题是什么，但是你在平台里，问题就在那等你解决？
+
+毕玄：技术人就是这样，你平台不够大，碰到的问题就不是世界级，可能别人早就碰到并且已经解决掉了，那你就不可能做很创新性的，最多结合公司的情况，做一个很好的工程落地，但你不可能引领。
+
+但大平台就不一样，你更有机会做出一个世界级的引领性解决方案，这对程序员，尤其做基础技术的人很重要，如果你想很好地发展，是很难离开大平台的。业务技术可能不大一样。
+
+比如说阿里，我很多好朋友更早就走了，他们当时都问我为什么还不走？我就说，在阿里这个平台上能看到的问题，其它公司都很难看到，关键是在阿里，我又有机会去做，等我做完了，如果我看不到还有什么问题觉得很难了，那再说。
+
+极客时间：看你当年的微博说除非去Google，不然你是不会跳槽的？
+
+毕玄：因为Google确实很让人羡慕，它看到的一定比我们更远，到现在我都很相信。
+
+极客时间：有人说你是“技术大牛”“毕大师”，这样的标签你怎么看？像“毕玄”这个花名本身也是一个标签，还是说你其实不在意这些？
+
+毕玄：所以我没换花名。
+
+极客时间：你对这些标签的感觉会有变化吗？
+
+毕玄：会有，我很多年前比较在乎。
+
+极客时间：比较在乎，是什么时候？
+
+毕玄：05、06年吧，进阿里之前。当时去参加小规模的技术讨论会，以前BEA经常搞User Group那种，我们这些小技术同学就去参加，觉得哇上面的人简直太偶像了，那个时候我们的梦想就是能不能认识这些人一起聊个天，以后能不能自己去讲。
+
+那个时候是很在乎的，最重要的就是希望能进入那个圈子。但我可能后来写了OSGi那篇文章，在那个圈子里，就觉得没什么了。
+
+再后来，我觉得技术最重要的是带来了什么。很多人会说自己技术好，那你到底用什么来证明呢？我觉得最好的证明肯定是，你做的东西对这家公司的整个业务发展有所作用。当然技术人可能还会追求别的，比如方案具备引领性，推动了这个技术领域的发展，那就更好了。
+
+像阿里，尽管我们是09年做的分布式改造，但即使到今天，做的思路至少影响了中国大部分互联网公司，后面做的异地多活、统一调度也在逐渐影响。
+
+极客时间：你们当年有觉得自己做的东西影响很大吗？
+
+毕玄：我们觉得这些外面都用不到。就像分布式，我们觉得大部分公司不需要分布式，但现在我们认可AWS讲的，现在的软件跟当年的差别很大，所以分布式成为很多公司的选择。
+
+做异地多活，我们更认为这玩意儿除了阿里、腾讯这种超级大的公司有诉求，中国其它公司应该都不算强烈，但这两年越来越多的公司开始去做这个方向，甚至国家比较重要业务的企事业单位都开始做。调度也一样，就很奇怪，Google其实做了很多年，中国也没有几家去跟进，但阿里做完，明显有好几家头部公司都在做了。
+
+对技术人员来讲，这种就很有成就感，因为别人讲到的时候都会提及，你看阿里是怎么做的，这就像我们说Google是怎么做的，就是信心，这很重要。
+
+极客时间：他们就不用再证明。
+
+毕玄：对，而且周期肯定会缩短，人才池也会扩大。当年我们做分布式碰到很多问题，但现在中国能做分布式架构的人简直太多，之前能做异地多活的人也少，但慢慢也能看到各家做过的人变多，调度以后也会是这样。
+
+
+
+
+
+　
+
+极客时间：当时你几次提离职，这么坚定，是想好自己之后要干什么了吗？
+
+毕玄：没有，但出来创业是确定的，创业干什么一点都不确定。所以我们现在也建议还是先想好你们到底要干什么，再出来，别冲动。因为创业跟在大公司差别非常大，我离职的时候跟很多人聊，总结出来就三个选择。
+
+第一，继续去一家大公司。找一家公司，任一个更高级别的位置，理论上也能做更大的事情，但后来我想了想觉得没有太大意思。现在没有多少平台让我觉得面临的问题多不一样，可能更多就是把我以前做过的去那边重新落地。
+
+而且所有大公司我相信不管是多高级别，你做事都会面临很多组织协作层面的问题，很多约束没法避免，因为大公司分工特别细，你要面对的横向部门会非常多，即使CEO也受很多限制，我想不出来什么职位不是，这很正常。所以我觉得大公司还是不考虑了。
+
+第二个去一家中等的在上升期的公司，可以去任职CTO跟随上市。很多人会选这个，我以前有个朋友梦想就是离开阿里以后去美国敲钟，所以他就选了一家即将上市的公司去任职高管。不管怎么样，梦想肯定实现了，那也可以的，我觉得挺好。
+
+但这个对我来讲，也没有太大意思，敲完钟然后呢？我就该走了吗？就没有太大的吸引力。所以只剩一个选择了——创业。还有退休，我觉得现在退休有点早，还是得再干几年。
+
+极客时间：还是想做点什么。
+
+毕玄：我们一帮技术人员，很多出来就一个原因，想找个机会做能再吹一把的事情，要的就是成就感。那成就感怎么来？就是前面讲的第一在公司有贡献，第二做的东西在业界有影响力，最好它还能被很多人用。
+
+我以前跟有些做管理的说，对成就感、对一个人是不是成功的判断，技术人员跟很多非技术的人，尤其高层的管理者，是不一样的，说得更极致一点，世界观是不一样的。
+
+对我们技术人来讲，只在乎你过往做了什么，你做了一个东西还能被很多人用，就是最牛的。像Trustin Lee做了Netty，更不用说Jeff Dean这种写了很多东西，还有写各种语言、框架的，我们不会在乎他在哪家公司任职，什么级别，带多少人，根本不Care好吗。
+
+极客时间：之前不是有个段子Python之父简历上只有一行字，I wrote Python。
+
+毕玄：对，最看重的是作品，但我们后来也发现，不仅技术是这样，事实上所有的都这样（笑）。
+
+你说即使是娱乐圈，大家也看你拍了什么电视电影，唱了什么歌，越多的肯定就越大牛，像周杰伦这种一长串的就是巨牛。其实都一样，等你老了，回顾人生的时候，没有人会记得你在哪家公司任职了高管，一点都不重要。淘宝总裁有多少任，没有人记得，你说你做过淘宝总裁，但大家都忘了你做过，这才是最悲剧的。
+
+好几个阿里出来的都是这个梦想，只是觉得在阿里确实有点难。想想自己大概还能工作多少年，阿里前面的事好像还挺值得吹下牛的，但我们发现如果再这样下去，就没什么可以吹的了，这就不大对劲了。
+
+极客时间：不太对劲？是指一直当管理的状态吗？
+
+毕玄：我们不希望到老了回顾人生的时候，发现全是更早的，中间有10年没有任何东西，那大家肯定会说你那10年都在混。因为我们这种人退休了八成都会做点咨询，做咨询肯定不希望自己谈的都是十几年前的案例，至少能稍微近一点，否则有点难。
+
+　
+
+
+
+　
+
+极客时间：离职后，创业是确定的，那当时你有想过内部创业吗？
+
+毕玄：如果你有机会在阿里做，确实没必要离开，何必呢？像玉伯做语雀挺好，你既然还在做一件足以吹一辈子的事情，那就继续干着，有人给钱，什么都不用你管，多好。因为想做一件大事，无非是找人、拿资源，在内部你去找上级、总裁要足够的支持，这就是一种资源。
+
+但是，我要做的事情不光要资源，还要横向部门的各种支持，比如要销售线、市场，这就很难，总裁也很难，因为他很难偏向你。
+
+以前我们想过，出来以后最大的损失是品牌，我们将失去阿里这个巨大的招牌，这是最值钱的，这确实是个非常大的伤害，但要资源也变得简单了，因为我只是找投资机构要钱，剩下所有都是自己决定。
+
+极客时间：这个硬币两面你们是可以接受的。
+
+毕玄：我出来创业前，很多阿里高管跟我说，创业也没你想得那么自由，最后你还会受限于股东、董事会等等。但必须说至少在前几年，你并不会受制于他们，自己有绝对话语权。
+
+极客时间：一个创业公司，前几年的规模，可能也没有到别人想要插手。
+
+毕玄：对，人家根本就不会插手，就你这，他还怕插手一下万一挂了。所以你考虑好两个问题就行。
+
+一你想做的事，到底是在阿里做成的概率更大？还是你出来做成的概率更大？如果出来的概率更大，那就别纠结了，你要想好你会失去什么，阿里的品牌，对很多人来讲还有阿里的待遇。
+
+二你能不能在这件事情上坚定地干个比如5-10年，在阿里说实话你要做一件事情5-10年很难，你可能自己想，但有一天你就被组织调了。
+
+极客时间：所以当时想清楚之后，你还是决定出来为自己的技术梦想奋斗一下。
+
+毕玄：但说实话我出来创业以后才发现，这个命题成不成立还要再想一下（笑）。
+
+因为创业还是一个非常商业的事情。技术梦想当然可以有，没有问题，我也很羡慕用技术梦想创业的人，我也想过，能不能做个东西让很多开发者用，如果能做出来就很成功了，至于这玩意儿到底能赚多少钱都不重要。
+
+但后来我觉得这有点不靠谱，因为你创办了一家公司，任何公司都是商业公司，想发展好，基础是这家公司能赚钱，这个当然很现实，技术的人都不太喜欢听。
+
+极客时间：成本、收益？
+
+毕玄：技术人不愿意听这个，很多阿里出来创业的就非常技术梦想型，我想做这个事情，对世界产生一些影响，至于赚多少钱我都不Care。
+
+但这种准确来讲，你不算创业，你只是换了个地方干活，然后你还需要上面有个人给你创造出一个空间来，这跟你在大厂的区别不是很大，可能还更难一点，因为你得在外面找个人盖住你，这个难度更大。
+
+创业最大问题就是这个，你必须考虑能不能创办一家未来具备持续盈利能力的公司，如果不具备，梦想就不可能实现，因为你做到一定阶段，公司倒闭了，那也没了。所以我们就一直在想到底能干什么。
+
+
+
+
+
+　
+
+极客时间：那想创业方向这事，你们想了多久？
+
+毕玄：很快的，我们出来以后，一两个月就基本确定要做什么了，无非就是几个方向想可能性。
+
+极客时间：你的思路是什么样的，可以具体讲讲吗？
+
+毕玄：像我们这样第一次创业的人，八成只能做自己擅长的，其他的概率非常低。
+
+比如我们看小鹏、雷军，你说后来雷军做手机，他难道懂手机吗？他肯定不懂，但是因为前面他成功经营了金山，小鹏也是，做汽车之前创办了UC。
+
+极客时间：第二次创业的时候有之前的创业经历做担保？
+
+毕玄：因为已经有足够的人脉圈和钱了，最重要的是钱，持续找钱的能力非常强，投资人就根本不在乎现在做的事他擅不擅长，你很靠谱，给你砸再多钱都行，赛道最好越大越好。
+
+现在我们说好后悔，如果你真的想做一家对世界影响非常大的公司，说实话，最好不要在大厂待太久，因为连续创业才有成功的可能。我不太相信一个人创办第一家公司就超级大，王兴之前折腾了好多家，黄峥也一样折腾了好多家，张一鸣也是，对不对？马云之前也创办了好多次。马化腾比较特殊，就创办了一家，运气比较好。
+
+极客时间：你说的，想创业大厂不能呆太久，是为什么？
+
+毕玄：在大公司，你最大的优势是带领过大团队，见过大平台大世面，所以你的公司如果未来能成长成一家很大的公司，大家相信你能带领好。但关键是你现在创业，能不能走到那步其实是更大的挑战。
+
+极客时间：你如果重来一遍的话，觉得自己什么时候出来更好？
+
+毕玄：也许上市后就可以走了（笑）。因为创业最好不要有太大经济压力，不然很容易变形，把公司做成目标就只有赚钱，这样会容易失去选择权。创办公司当然要赚钱，但选择还是需要的，比如说短期有些钱，如果对公司业务发展没什么意义，就不要赚好了，没有什么，亏损就亏损，你是能接受的。
+
+但你想，如果创业者压力那么大，公司很容易出问题，他如果真的很缺钱，比如连生活都有问题，我觉得会不择一切手段。所以我也很佩服以前创业的一帮人，压上所有身家，哇简直太牛了。
+
+极客时间：现在大家已经习惯了创业要找融资。
+
+毕玄：都有退路，以前都是All in。
+
+极客时间：中国的投资环境也在成熟，但刚刚讲到第一次创业，国外成功的好像多一点。
+
+毕玄：国外也比较特殊，很神奇，你看微软，盖茨之前没干过啥，Facebook，马克也没干过啥，上来一把成功，Google也是。
+
+我觉得是因为国外卷得没有中国厉害，他们如果面对一些成熟的创业者，我觉得也干不过。但中国，你如果真的想做对社会影响非常大的赛道，除非以前就是这个赛道的人，那很幸运，就像很多做芯片，做机器人的，他以前背景就是这个，像我们这种就没办法。
+
+To be continued……
+
+　
+
+水友讨论区
+
+对谈到这里就暂时结束了。今天的重点话题是毕玄对自己在阿里14年工作生涯的反思。
+
+对于工作中的成就，他说“说实话这就是幸运，因为换一波人也一样能做好。”聊到工作中的成就感来源，他说技术人的成就感很简单，第一在公司有贡献，第二做的东西在业界有影响力，最好第三还能被很多人用。
+
+至于为什么会离职？他的回答背后折射出来的是对个人成长的高度关注，理由也很简单，因为这个平台不太能让他再做值得吹一把牛的事了。聊到这里，突然想起李诞写的脱口秀工作手册：“工作的本质是交易，我们在用自己的时间和才能，通过一家公司，与市场交换金钱。要意识到你的全部人生都理应要为你的创作提供养分，为它服务。好的工作节奏，就包含了学习，包含了养分。”
+
+如果让你对自己的学习/工作生涯做一次总结，你会说什么呢？你觉得自己的高光时刻有哪些？光环是平台带来的，还是个人能力带来的呢？你的成就感来自哪里？你现在正做的东西有给你带来成就感吗？
+
+期待在评论区见到你的身影，如果对今天对谈的其他内容有感想，也欢迎你发言讨论。
+
+下一讲我们会接着毕玄思考自己创业方向的思路聊，下一讲见。
+
+拓展阅读
+
+1. 浅黑科技就腾讯上云的过程写过一篇文，毕玄说和阿里当年经历非常类似：腾讯在命运的棋盘上砸下一颗钉子
+
+2. ArchSummit 全球架构师峰会 2019 北京站有一次演讲：把阿里巴巴的核心系统搬到云上，架构上的挑战与演进是什么？
+
+3. 毕玄离职的时候写了一篇对过去的总结和未来展望：再见，阿里毕玄
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/11CEO心得：大厂出来创业，最大问题是对钱没概念.md

@@ -0,0 +1,272 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            11 CEO心得：大厂出来创业，最大问题是对钱没概念
+                            
+你好，我是叶芊。-
+　-
+在一段波折的离职过程后，毕玄从阿里出来了，决定创业，但他却完全没想好自己要做什么。-
+　-
+回顾他的职业生涯，异地多活、代码工具、统一调度都挺有市场的，他也提到自己差点就去做代码了，投资都快谈完了，最后想了想还是悬崖勒马改做现在的调度。今天我们就接着创业继续聊，看看他是怎么选择创业方向的。-
+　-
+你可能暂时对创业不太感兴趣，没关系，听一听这位技术大牛对市场以及个人优劣势的分析，相信对你之后的职业发展也会有帮助。
+
+
+　-
+极客时间：之前聊到创业方向的选择，第一点是选一个自己相对有优势的领域，然后呢？
+
+毕玄：第二点我们特别关注的，从商业模式上来讲具不具备盈利的可能性。盈利，最重要的是你对客户的价值是什么？如果有价值，客户是肯定愿意付费的，所以关键是价值。
+
+我们第一想法是代码相关，这对开发者影响是最大的，所有的人都会用。所以代码智能化其实是我们考虑的第一方向，几乎都谈完了。但最后我觉得，最大的问题是我们团队没有优势，之前有希望做成是因为阿里的环境，但离开了，就要跟GitHub对着做，但是跟他们比，我们一点优势都没有，这玩意儿咋成功？
+
+另外商业周期非常长，GitHub已经算很快了，但它做了两三年，现在也只是推进到了一定阶段。但在中国，你从开始到商业化可能要5年以上，那就要考虑一下5年你的公司持续没有收入，生存就得靠不断地融资，这难度太大了。
+
+极客时间：而且就像你说的，技术的人，持续找钱的能力相对没那么强？
+
+毕玄：对。而且大公司的人最大的问题是做所有事情没有成本概念，这才是悲剧。
+
+比如说我，以前就算财务给我一个数，一年亏了多少亿，我也没有任何感觉，反正不是我出钱，有人出，而且还会觉得亏了这么多亿又怎么样？我还得加人。你就会把这个故事讲下去，一点都不在乎，因为你亏损了不用自己去融。
+
+大家对钱没有概念，很多大厂出来创业的人，钱都不知道花哪去了，稀里哗啦就没了，心里觉得相比以前，现在才这点钱，随便花，然后就没有钱了。
+
+在阿里，你说服了上面给你投资源做一件事情，失败了最多也就是年底绩效差一点，奖金少一点，没有别的了，不会失业也不会倒闭。但出来了这都是事实，你没有钱，公司就倒闭了，员工是很难跟你讲梦想的，先必须有合理的报酬，梦想只是个加分项而已。
+
+极客时间：所以代码方向还是大厂有优势，你当时还想过什么方向吗？
+
+毕玄：另一个就是中国现在特别火的开源，人简直太多了，做大数据的、做数据库的，不知道有多少家，一面墙都不一定能写完（笑），已经卷成比花卷还卷了。
+
+对技术创业来讲，选这条路，你前几年还是挺爽的，因为你要考虑的是用户不是客户，用户都是免费的，免费好谈，你可以刷脸，别人用着合适还可以帮你推广站台，都没问题，如果前几年你还能融到资，生活简直不要太爽，就乌托邦。
+
+但是我觉得，到了某一年，你需要尝试商业化的时候可能会面临非常巨大的挑战，尤其在中国。你看，有哪家公司通过开源积累了大量开发者，最后通过漏斗效应商业化成功的？就现在看，我觉得八成是不大可能。
+
+极客时间：为什么国内商业化成功不大可能？大家对付费的观点不同？
+
+毕玄：你想中国市场购买技术软件的是什么行业？多数是金融，但金融又不会单为一个技术软件付钱，它是大项目招标，里面包含技术软件。除非你有能力直接去投标，不然就得在上面做一些应用软件。这种阿里云可以，因为阿里云有品牌，他其实也不是自己干，他也只卖下面基础设施，上面可以找合作伙伴，但你很难，你一家创业公司凭什么？
+
+而且大家去见客户，免费的情况下也是什么都好谈，随便谈，但只要说到要收一块钱就是另外一回事，这就变成了公司行为，不是个人的，公司对公司是一个非常正规的行为，因为决策不一定是他能做的，而且金额越大，决策链条一定会越长，不管什么公司。
+
+极客时间：但是国外有很多开源到商业化的成功案例，如果参考国外经验呢，中国公司从开源到商业化的路？
+
+毕玄：海外没有问题，像Confluent、Elastic、Mongo等等，都成功走完从开源到商业化的过程，每个季度的营收都在几个亿美金，增速非常快，虽然还是亏损的，但你至少能看到希望。
+
+但现在缺的是人才，到底去哪找一些人，把开源产品在欧美完成商业化。如果有谁能走通这条路，对中国的软件产业会是巨大贡献，只要有一家走通，关键人才就有了，以中国的复制能力，一家公司有了，中国就全有了，这不是问题，现在主要是没有人。
+
+极客时间：对做开源的公司来说，以前大家会讲亚马逊的故事，人家强势，我就是不盈利。不能这样吗？
+
+毕玄：但你看他最终还是盈利了，而且一把就赚回来了。大家愿意投你钱，是因为他相信你一把可以赚回我以前投给你的所有的钱。
+
+而且ToC是有可能一把赚回的，但ToB不可能，这个逻辑根本就不成立。所以这些开源商业化的公司还真是要看一下，因为美国这几家已经很成功了，一年营收接近10亿美金，增速70-80%，但仍然亏损，这太恐怖了，这样下去你到底能不能盈利？如果不能盈利，这其实是个泡沫，对商业公司来讲什么叫泡沫？就是这个，能盈利你就不是泡沫，不能光讲梦想。
+
+如果可能性是存在的就可以了，就有信心，对一家公司来讲说实话这就是最重要的，尤其对创始人团队，这伙人是很苦逼的，因为就是熬，你得熬很多年，不到盈亏平衡的那一天，其实都不算熬出头。但到那一天情况会好非常多，很多都变了。
+
+极客时间：所以现状是没一个跑通，又不能靠画饼，那中国的企业从开源到商业化，你觉得有希望吗？
+
+毕玄：我觉得肯定会有，无非是几年的问题，以及是谁的问题。这条路也确实是技术人员创业最好的选择，阿里出来了这么多人创业，多数选择的也都是这条路。
+
+因为中国已经进步了一点。以前开源，很少有中国人做的东西是主导，或者中国人做出来影响了全世界，但现在有了。现在除了最底层的核心技术，中国在应用层的技术能力是可以跟国外抗衡的，没有太大差距，中国的场景又更丰富，能诞生出很好的开源产品，然后影响全世界。这个套路已经成熟了。
+
+有些投资人赌也是对的，他们为什么很愿意投这些。我之前很震惊的，因为商业上很难讲通，但他们说其实很简单，他们相信中国一定会有一家走通的，是谁倒不重要，他只要押大赛道就可以了，只要有一家成功就没有问题，但小赛道还是不要押，成功了回报也很低。
+
+极客时间：看我们讲到的几个领域，代码智能化、开源数据库等，这些方向都挺好，但是你认真想过还是决定算了。
+
+毕玄：都挺好，我也挺想做，但以我们创始团队的背景，如果创办一家公司我觉得最好不要做这种。
+
+创办一家公司，一做自己相对有优势的，二做对客户来讲是可以直接讲清楚价值的，因为这样商业模式和收费才能闭环，如果能完成这两步，我觉得未来这家公司是有可能走向盈利的。
+
+如果你想做对社会有更大影响的大赛道，或者就纯粹想Buying一个梦想，最好你先创办一家成功的公司，做成具备盈利能力并且能持续盈利的，那个时候再投一点钱去梦想，或者再做对社会影响力大的陌生领域就可以了。有了很好很健康的现金流，你随意好了，想做什么领域都可以，像阿里，阿里云能做为什么？就是有淘宝，能持续产生健康的现金流。
+
+
+
+
+
+　
+
+极客时间：你最后选择了做调度，你怎么看这个方向的，可以多讲下吗？
+
+毕玄：看我们在阿里的经历，有什么事情是相对外面有优势的，也要相对可能被产品化和规模化的，另外对客户有价值的，我们觉得只有调度有可能，其它都很难。
+
+异地多活具备领先性，但它不具备通用性，所以如果做这个方向，会做成一家咨询公司，但咨询是我们退休的目标，不是现在，而且咨询不可能做大，虽然比较赚钱。因为我们现在发现，总体顺势而为还是很重要的。
+
+像国外，FinOps（云成本优化）要开始起来了，算是个新词，一个方向火没火最容易判断的就是，看有没有越来越多的创业公司，并且拿到了不错的融资，过去一年，国外做FinOps拿几千万美金融资的公司已经出现了。
+
+但中国FinOps还是一个概念，还没有能说出一家公司确实做出名堂的，当然这对我们来讲就是一个非常好的现象。
+
+极客时间：如果FinOps还在概念阶段，那客户容易理解你的产品价值吗？
+
+毕玄：FinOps对客户的价值现在是被认可的。因为很多公司上云之后，发现成本完全不受控，原因是云太好用了。
+
+以前不在云上的时候，机器的采购内部要过很多流程，还要真实地去买，物流都需要时间，但在云上可不是这样，你点一下就买来一台，而且钱还不是现在付，是一个月后付，所以就失控了。连我们这样的创业公司都出现了，到了月底，一看帐单，怎么花了这么多钱？所以我们相信这个问题确实存在。
+
+另外是服务器成本控制，我们觉得阿里应该是做得非常好的一家，方法是有效果的，也是可以通用的，这对客户来讲是有价值的，尤其大环境都在喊降本增效。
+
+为什么FinOps刚好在现在这个时间点火了？一是云的便利性带来了成本失控，二是以前大家都不Care成本而已，现在这个方法可能会被大家认可，所以我们觉得这个帽子对大家来讲不是那么虚幻的话题。
+
+极客时间：有一点好奇，在服务器成本控制这个方面，除了你们在做的这种方案，有其他的方法吗？
+
+毕玄：我们觉得没有。
+
+全球很多公司探索这个方向，但目前来看只有Google、阿里和百度在非常成功地往前推进，而且结果也证明是有效果的，其他公司都很难，所以现在中国头部公司做的方案都很类似。
+
+而且做这件事涉及的专业领域很多，像我们为什么要这么多人？因为需要大数据团队、调度团队、操作系统内核团队，我们总共有5个合伙人，全是技术出身，覆盖了几乎各个技术领域。但对中型很多公司来讲，要组建三个这样的专业技术团队其实很难。
+
+这意味着可能要投入比如四五十个人纯做技术，但一家中型公司的研发人员就那么多，很难投到这个数量，就算能投，但中国做过这件事情的人特别少，反正就这几家，就这伙人。如果他们不出来，其实基本也都不出来，你没有经验自己做，阿里都花了三年，我们觉得你不会比阿里快。
+
+所以我们给公司的定位是，不是说你不能做，是我们可以加速你的整个进程，先让你快速拿到一定成果，对中型公司来讲这很重要，他们要的就是尽快拿结果，而不是在这里浪费太多时间。等他拿到结果，你要继续往下发展的，是没有问题。
+
+
+
+
+
+　
+
+极客时间：你现在做的调度产品是什么样的模式？
+
+毕玄：它比较像PaaS，至少目前阶段的产品形态，你可以认为就是一个PaaS软件，可以部署在各种环境下，私有云、公共云等等，部署完客户做对接，基本就可以了。
+
+
+贝联珠贯，打造全球顶尖的资源调度产品，将全球企业的资源利用率提升到20%以上，从而显著降低各企业每年投入的机器总预算，节能减排促进碳中和。技术栈基于K8S/Yarn构建，对K8S/Yarn的关键部分做深度开发和定制，提升其规模能力、稳定性，以及多云/混合云管理，包括离在线等不同计算形态的混合部署。
+
+
+极客时间：这和你之前在阿里做的统一调度？
+
+毕玄：区别就是更加产品化，就这一点。
+
+阿里或者说任何公司，内部做的东西都只是贴合那一家公司做的一个特殊的解决方案，阿里以前都叫一个能力。但出来你要把这个能力变成一个产品，能面对各种各样的场景，这是很不一样的。
+
+因为能力，不需要考虑很多运行环境，环境就是设定好的，我只是解决这个环境下的问题，但现在你不知道客户是什么情况，能不能有个产品通用，说白了，比如A客户是这样的，我投了10个人做，在做B客户的时候不用投10个人，那就是产品。
+
+所以你想，一家公司最后能盈利是因为产品的边际效应产生了，比如我总共50个人研发，第一个客户10个人做，第二个6个人，第三个可能只投了2个人，这就有了。如果不能就完蛋了，做一个10人，二个10，第三个客户还是10，这样研发是做不下去的，没有边际效应。SaaS为什么大家都觉得很好？是因为边际效应太强了，你投了一把，后面就躺着数钱。
+
+极客时间：那对调度来说，你觉得有办法实现边际效应吗？因为每个公司的技术基础肯定不一样。
+
+毕玄：对，会不一样，但我们希望能产生边际效应。交付成本肯定都是需要的，无非是成本我怎么收敛。
+
+第一个项目一定投入非常大，搞不好是整个公司，但第二个客户我必须把这个成本压下去，压到一个数的时候最后我算嘛，总体投入是多少，我从每个客户身上能获得多少利润，然后算边际效应是多少，这里我就有一个很好的定价了，但前面的定价肯定是不那么合理的。
+
+所以定价这个事，在大公司是不可能感受出来的，以这个产品的定价，要做到多少客户才盈利，很多人搞不好算一下发现自己永远都不可能，那就成做慈善了。当然大公司有很多补充，我这里可能是亏的，但带来了其它的，所以总体是盈利的。
+
+但你小的创业公司就一个东西，所以别想太多，如果不赚钱，你就是不赚钱，而且会永远不赚钱，关键是你不赚钱公司迟早会倒闭，因为我不相信有人融资能力是无限的，公司一直亏损，还一直有人给钱，哇塞这也是见鬼了。
+
+极客时间：现在像定价、财务这块，自己是在补课吗？
+
+毕玄：那必须补，还有行政，经营公司的各种乱七八糟的事情。
+
+CEO不就是这样，很多技术人出来创业肯定想做很多技术什么的，别扯了，你出来以后就会发现，CEO就是一个打杂的，公司什么事没人干就是CEO干，如果有人干，你最好就不要干了，你就别管了，那个人如果你很信任的话就是这样。
+
+以前在大公司你完全不用经历，都有人在背后帮你全搞定，但你出来以后不可能，除非你有这样的合伙人，但多数技术又没有，所以你全部得自己学。像财务，你得始终知道自己哪天会倒闭，哪天手上的钱就会没有了，这太重要了。
+
+我们现在非常羡慕出来创业后能打平甚至盈利的，这才是公司。
+
+极客时间：为什么？如果打平了，就验证了公司的业务方向是可行的？
+
+毕玄：打平了节奏就都在你手上（笑），而且你的心态会很安稳，否则你永远都活在会不会哪天就没有钱的噩梦里，想下个月怎么发工资，这个时候不管你有什么梦想，其实都没有意义，有啥意义？你首先得有钱。
+
+我们一帮出来创业的CEO们，现在聊天已经没有人聊这些很虚幻的梦想了，都只谈大家手上的钱还够不够，够多久。
+
+极客时间：不谈梦想，大家现实地互相勉励。比较理想的情况要屯几个月的钱？
+
+毕玄：现在的融资环境，至少要一年半以上，我们都是按照18个月准备的，就是未来18个月里没有一分钱的收入，这家公司也能活下去，如果不能的话，风险会比较大。
+
+　
+
+
+
+　
+
+极客时间：你现在做的调度领域，有没有期待什么时候自己可以打平？
+
+毕玄：那早了去了。ToB太难了，一开始赚不了钱，后面你也很难讲能赚回来，千万别讲ToC的故事，我前面几年亏了多少钱，后面会一年把钱全部赚回来。
+
+极客时间：你觉得ToB想打平要积累多久？或者说公司一般发展的节奏是什么样的？
+
+毕玄：至少3年以上。你看ToB做一个新东西，第一年说实话就是种子客户培养，如果种子客户做得很好，到第二年，你基于种子客户的赛道可以做规模化复制，就是复制多少个的问题，第三年看你能不能扩到一个更大的领域，不限赛道通用的，或者如果能在全球化上有所展现，这样的公司未来就很有可能发展得非常好。这是最理想的节奏。
+
+极客时间：第三年你提到“全球化”，这个之前还挺少提的。
+
+毕玄：全球化是个很有意思的技术新命题，因为在中国，技术人以前没有见过全球化，有什么新问题很难说，但我觉得我们这种人是做不了的。
+
+极客时间：创始人的文化背景不一样？
+
+毕玄：差太远了，中国做全球化成功的几个业务，创始人基本都在海外生活了很多年，非常知道海外跟中国的异同是什么。
+
+你看马云那一代创始人，跟移动互联网这一代差别很大，你可以认为他们确实偏草根，其实也没有那么草根，只是看起来偏草根，但到了移动互联网这一代全是精英，基本全是名校的，也都有海外背景，像张一鸣、王兴这些人天然对多元化文化有更深的理解，注定他们这一代有可能成为更好的企业家。
+
+我觉得这是创始人基因决定的，没法弥补，即使老一代创始人你招了一个也没法弥补，因为过往太成功了，他肯定觉得我更懂，你们懂个啥。但新一代不一样了。
+
+极客时间：新一代的创始人，面对的是新一代的问题？
+
+毕玄：对，他们就会去解决。美国为什么能做好全球化，他们小孩一出生面对的就是各个国家的人，他觉得这不很正常吗？但中国根本没这环境。
+
+极客时间：你现在是在创业的第一年，感受怎么样？
+
+毕玄：第一年你还在相对乌托邦阶段，还在蒙头做一个自己觉得对这个世界很有价值的产品，是最爽的，拿了融资尤其，一你不缺钱，二业务增长也不是你这个阶段最重要的目标，诉求还不会很强烈，没有到比如要追求盈亏平衡，自己能做一两家，就已经觉得我这产品太成功了。
+
+但等见到真正的客户让他付钱的时候，你可能就发现原来根本不是这样，就吐血了，而且后面业务压力会很明显，第二年可能就会期待你做复制的速度，第三年可能要求高增长，甚至开始要求你打平。大家觉得创业第一步就很痛苦，但后来你会越来越痛苦（笑）。
+
+我们节奏不算太慢，去年11月成立的，到今年6月左右就开始接触外部客户，我就跟团队说美好的时代要结束了。
+
+你会看到客户跟你想的肯定有一个GAP，还可能很大，这很正常，当然就看你怎么看待，像我们就觉得挺好，至少说明客户对我们还是有点兴趣的，虽然有GAP，但客户对我们有兴趣，只要弥补这个GAP，我们还是有点机会的嘛。
+
+当然你也会有另外的打击，比如说拜访很多家客户可能最后感兴趣的就是几家，这就看你怎么接受了，因为这就是失去品牌后最大的问题，所以创业公司确实比较难。
+
+
+
+
+
+　
+
+极客时间：在产品的运作节奏上，有做市场、品牌这些事吗？
+
+毕玄：我自己的看法，这取决于你公司定位的客户类型。比如说如果你做开源，那不用说了，肯定是要重点做品牌，做社区的运营，重兵配备。
+
+但做ToB很多是商业的，像我们，每一个客户都是商业的，不存在免费用户，而且我们做的是中大型，他们其实不大会受Marketing和品牌的影响，因为中大客户没有多少是我网上看篇文章、听到哪家公司，来找你问一下能不能提供个什么卖给我，这不大会发生。
+
+另外销售来了其实也没有用，之前我们见了很多客户，可能有20多家，很多对我们有兴趣，但我们后来都很害怕。
+
+极客时间：啊见了这么多客户，也都有兴趣，为什么会很害怕？
+
+毕玄：说实话我们的成功率还是不错的，客户觉得挺有意思，就会说要不你们来测试一下。但最大问题是我们自己并没有准备得那么好。
+
+极客时间：没准备好，是因为你们初版产品还在做？
+
+毕玄：比如说有四五家，让我们同时去试一下，但我们没有这个人力。所以后来我们7月份叫停了所有的客户拜访，都不去见了，我们觉得目前已经有明确可以共建的客户了，就先做好这些，其它的不用纠结，我们相信只要做好了，至少在中国目前的情况下，那几家应该还是我们的。
+
+极客时间：所以你们去找这些客户的策略是什么？
+
+毕玄：逻辑很简单。首先我们认为中大公司一定有自己的客户群体，剩下就是一家一家拜访，当然你肯定先选赛道里最头部、最有影响力的，所以这种情况下反而越低调越好。
+
+因为你现在没有客户，太高调在中国真不是好事，卷得非常厉害的，抄袭也非常严重，你最好能非常低调地出现在各中大客户的名单里，毕竟市场可能就这些客户，谁先做掉这里面的大部分，谁就赢了。
+
+等需要做品牌的时候，其实我已经占领了不少客户了，需要更规模化的。但前期我们觉得那些一点用都没有。
+
+极客时间：前期的客户触达具体是怎么做的？
+
+毕玄：刷脸。因为你创业不可能什么资源都没有，肯定或多或少有点，然后就要去拜访这些人。
+
+但比较难的是因为我们每一个客户都是要付费的，加上单价又比较高，不是大家随便帮你刷个脸就可以的。付费到一定金额就非常复杂，决策链长决策成本高，创业公司又没有品牌，我为什么要选择你？光这个问题在内部都能被挑战到死，你跟那个人关系是很好，但你为什么要定向采购这一家？会不会涉及利益？为什么不引入更多家供应商比价？
+
+种子客户是纯属刷脸和信任，根本没什么别的，否则别人只要问你有客户Case吗？没有，你就已经出局了。但是创业公司第一步如果刷不到种子客户，基本就没有什么希望了。
+
+　
+
+水友讨论区
+
+今天的对谈到这里就暂时结束了，重点聊的是毕玄对创业的思考和认知，毕竟做复杂的业务，认知决定了产品成熟度。
+
+这是他的第一次创业，在选择方向时，逻辑主要有三点：自己相对有优势具备领先性、相对能产品化和规模化、商业模式具备盈利性。
+
+代码智能化方向他认为不满足第1点，异地多活不具备第2点，现在大火的开源方向在他看来暂时还不太满足第3点，所以为了成立一家真正的公司，他选择做调度，成为了一名在创业公司“打杂”的CEO。你在选择自己之后的从业方向和公司时，3点判断标准其实也可以借鉴。
+
+不知道你对今天对谈的哪个部分印象比较深刻，欢迎留言讨论。
+
+到这里，毕玄个人的20年程序人生我们就聊完了。后面我还更新了一讲番外，聊一聊一切的开始——毕玄的大学经历，希望了解毕玄接触计算机的初心，把他的早期想法展现出来，与他后期观点形成对比，看看我们是否能找到他在面临无数人生选择时的底层逻辑。
+
+拓展阅读
+
+作为一个喜欢写文章的人，自己的人生翻开了新的一页也少不了会手痒想写上一篇，之前毕玄就创业写了这篇：凡是过往，皆为序章，凡是未来，皆有可期
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/团队：在人身上，你到底愿意花多大精力？.md

@@ -0,0 +1,294 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            团队：在人身上，你到底愿意花多大精力？
+                            
+你好，我是叶芊。-
+　-
+今天我们讨论怎么带团队这个话题，哎先别急着走，你可能跟很多人一样，觉得带团队离我还太远，或者觉得我才不要做管理，我要一路技术走到底，但是你知道吗？带团队做事，其实本质不是你认为的怎么管人的问题。-
+　-
+不管你对管理抱着什么样的认知，在对谈开始之际，我们先抱着空杯的心态，看看毕玄这个不愿意做管理但还是带了十年团队的人，他是怎么理解Leader的，他的灵魂三问一定会给你启发。
+
+
+　-
+极客时间：之前聊你带过的项目，你提“被任命”很多，感觉你不是很愿意做管理，但是还是做了这么多团队的管理，为什么？你对Leader这个词是怎么理解的？
+
+毕玄：这个变化，我自己觉得最大的原因是T4、异地多活的经历。T4，我带了一个很大的虚拟团队去做一个很大的事情，也拿到了一个相对不错的结果，但比起对我的影响，对其他人的影响是小很多的，这个状况我不是很喜欢。异地多活也是。
+
+后来看运维团队的时候我更觉得，对一家公司来讲，一个组织能不能往前发展是更重要的，如果你想改变，就必须成为Leader，这不带团队是不可能的。所以两件事都让我觉得，如果你想对这个公司有更大的贡献，就必须带领更大的团队。
+
+极客时间：所以就你来看，比如一位开发同学想成为Leader，需要关注哪些方面，会遇到哪些问题？
+
+毕玄：我觉得就是个心态。阿里给新管理者的培训，尤其我们技术线，要解决的第一个核心问题就是心态，因为很多人是我根本不想做Leader，你们觉得我技术很好，干活能力不错，所以就硬把我摁到了那个位置，所以他不觉得是个提拔，他觉得你这是坑我。
+
+技术人会很害怕做管理以后，精力受到影响，最后导致我好像日常都在干一些很虚的事情，以后会不会工作都找不到了。但如果我一直写代码，至少找工作不会是大问题，尽管现在说什么35岁，但事实上如果你写代码能力强，确实就不存在找工作的问题，因为技能永远都在。这是技术人很正常的想法。
+
+所以这第一关，很多技术人就很难过。但我跟很多人说最起码你应该试一下，有些人可能试了一下之后觉得也挺好能接受，如果试一下你真的觉得接受不了，那你就专心做一个程序员，其实也没什么。
+
+极客时间：技术人想做管理，首先培训对管理的认知，从太虚了出去肯定找不到工作，变成带一帮人成事。那跟人打交道这个方面会有问题吗？
+
+毕玄：第二个很难迈过去的关就是看到人这个层面的问题。因为多数人选择做程序员就是不想跟人打交道，只想跟机器打交道，这一做管理者就完蛋了，你不可避免要跟人打交道，不然这个团队肯定会有些问题的。你可能觉得我只要做事就行了，但关键是你要做的事情谁来干？另外你怎么排兵布阵？你必须了解他才能排兵布阵。所以这一关我觉得技术人更难迈过去。
+
+极客时间：这关你是怎么过的？
+
+毕玄：最大的前提还是我认可那一点，只有带领团队，才能做更大的事情，对这家公司才能有更大的影响。你就自己先想好，是觉得做一个专业人员更好，还是觉得做一个带领更大团队的Leader更好，而且要知道Leader也有很多种类型。
+
+之前很多人不断让我带团队，但我一直拒绝，因为我在带100人的运维团队之前，规模就一直控制在20-30人，从来没有超过，而且说实话这种还不大存在管理问题，你稍微分出一点点精力就可以了，所以我很难理解现在为什么带20-30个人会有问题。
+
+极客时间：为什么？因为20-30人团队规模小，管理比较简单，就是带着一帮兄弟做事？
+
+毕玄：因为20-30个人你很容易熟。每个人，我都知道他们在干啥，也大概知道他们的能力状况，而且我也不需要付出太大的精力。但带到100人的时候，很多人我都不一定认识，跟我有很多交互的就更少，非常少。
+
+但我带团队的路线并不好。我是从20-30人上来就开始带100人，然后可能带了半年左右就变成带三四百的团队了，后来就带600多人，这不是个正常的路线。很多东西你会搞不太清楚，因为中间隔的层级变化太快，带100人你可能隔了一两层，但带600人就隔了很多层，但我的管理幅度最多只能到向下两级。
+
+
+
+
+
+　
+
+极客时间：那你觉得怎样才能成为一个好的Leader呢？结合你自己从20-30人、100人，最后到600多人的管理经历，有哪些是你当时没做好，现在可以做好的？
+
+毕玄：其实核心还是花精力的问题，就是在人身上，你愿意花多久的精力。
+
+当时15年下半年带100人的运维团队，那100人我都比较熟，因为我们一起战斗过，做过好多项目，大家跟我打交道非常多，所以我去带的压力没有那么大。而且我带的那个时间点刚好是阿里最重要的谈年度绩效，谈完几个月后团队就解散了，理论上是Leader最痛苦的半年，但因为我们大家都比较熟，谈得也没有很辛苦。
+
+但后来16年带600人了，你发现一个最大的问题就是这些人你不熟，你到底怎么办？
+
+我以前带团队做得相对最好的是，对团队走向什么方向，我有自己的看法，然后我会告诉所有的人，但是你想好了方向之后，在团队里你到底怎么安排大家去把这些事情做好？怎么排兵布阵？怎么落实？这些当时我是有很大差距的，因为这里很关键的问题就是你对这个团队到底有多了解。
+
+为什么很多Leader都喜欢用自己的老搭档，换一个领域他把那帮人又拉过来，就是因为不用磨合，大家都熟悉，就很简单。但你面对全新团队的时候就很难，你得愿意花精力。
+
+极客时间：以前你没做好是为什么？因为自己不太愿意花精力了解人？
+
+毕玄：不愿意，我觉得那简直太累了，要了解一个人是很痛苦的过程，你要跟很多人聊天，得花非常大的时间和精力，技术人都不是很喜欢这个事情。
+
+极客时间：聊天这么必要吗？不能说用很好的协作工具交流吗？
+
+毕玄：工作可以，但工作之外，你只能靠跟人聊才能有更多的了解。
+
+极客时间：工作之外的东西是想看到什么？
+
+毕玄：有些时候我们需要看到的是一个更立体的人，我需要看到你在其它方面的一些状况，因为我们最关心的还是你的空间问题。
+
+极客时间：个人成长？
+
+毕玄：对，就个人的空间问题，还有你对这个团队的看法。我以前只跟他们聊三个问题。
+
+　
+
+
+
+　
+
+毕玄：第一个问题，虽然HR很不希望我问，但我基本都会问，就是你离开阿里巴巴的时候，你会找一份什么工作？我觉得这就是你的职业规划，如果你想过这个问题，我们就可以更好地规划你在阿里的路径。
+
+因为说实话你不是一定要在我的部门，我是很无所谓的，如果你觉得去另外一个部门对你更好，那就去，我觉得这样对公司也是更好的，因为你自己有动力在，所以我从来不强制要求。很多Leader可能会放大这个，觉得怎么样，但我觉得把它放大也没什么用，说实话还不如给另外的人一些机会。
+
+但你会发现很多人其实没有想过这个问题。
+
+极客时间：对这个问题有想法的，大概是什么比例？
+
+毕玄：这就看级别，很明显的，级别越高的人通常越想过。
+
+但是你没想过，后果很惨的，因为有可能有一天不是你要离开阿里巴巴，是阿里巴巴要你离开，这很正常，现在不就上演了？以前大家信心太强了，觉得公司发展得这么好，我怎么可能会走？或者阿里怎么可能让我走？但现在再看看，很多人出来真的傻了，根本不知道该怎么办，这就悲剧了。
+
+如果你想过就会好很多，因为早就有所准备了。如果你实在搞不清楚自己的情况，你也可以去外面面试一下摸个底，这样你能立刻对自己有更好的判断，我们不反对这件事，因为阿里这个平台对多数人有极大的吸引力，很多人根本离不开。
+
+极客时间：职业规划这事，你自己是怎么做的？一般会做多久？
+
+毕玄：我不会做太久，但我肯定会想出来以后的几种可能性，不是说你一定要固定下来做什么，但要有可能性，这样你可以反推自己每一年要怎么发展。
+
+我们肯定希望每一年对自己的职业生涯都是有帮助的，多数人的职业生涯都在几十年，看起来很长，其实很短，像我们这帮人尤其，剩下的很短了，每一年都特别重要，错过就错过了，就没有了。
+
+所以你要想好，也许这家公司不能给你符合你的回报，但只要职业生涯你是一直在成长的，总有一家公司会给你，那纠结个什么？你纠结也没有意义，因为你可能在阿里混得很好，但真的有一天要走了，那你怎么办？
+
+极客时间：所以第一个问题其实是作为Leader要关注团队同学比较长远的职业规划，也要帮他们去关注，那你聊的第二个问题是什么？
+
+毕玄：第二个我会问的就是，过去一年你觉得对你职业生涯是加分、减分还是持平，能不能写进简历？
+
+一个人，比如我在阿里工作14年，我不会说这14年里每年做了什么，我只会告诉你在阿里我做了三件事，这意味着中途肯定有几年是我觉得没必要提的，因为提了对我找工作没什么帮助。所有你觉得值得写进简历的事情，肯定对你是加分的。
+
+这个问题是很落地的，我不是跟你谈虚的，问对你的职业生涯有没有帮助这种，员工当然告诉你有，但如果你问他会不会写进简历，有些人是会告诉你真话的，没有必要写。那你就要想一下你给他的空间是不是有问题。因为这种人如果真的很有能力，你这么带一两年，他肯定走了。
+
+第三个我会问他对团队的一些看法，觉得有没有什么问题之类的，很轻松的，大家随便聊。但这个聊完其实对他会有很大影响，如果你对团队问题很有思考和想法，Leader就能结合你的发展潜力和职业规划，来更好地安排位置，帮助你成长。
+
+极客时间：对团队的看法，会提到工作吗？
+
+毕玄：这个跟实际工作没有什么关系，对过去一年的工作做点评那是另外绩效的事。
+
+　
+
+
+
+　
+
+极客时间：你当时带团队的时候认为Leader核心是要在团队的人身上花精力，人熟了团队就很好带，所以你就想用这三个问题来了解他们？这是带600人大团队的时候你问的？
+
+毕玄：对，我给自己定了指标，跟100个P8聊天，一定要跟这些人至少聊一次。
+
+极客时间：当时怎么开展的？有周期吗？
+
+毕玄：一般是隔一个季度，我会先聊一圈，每个人半个多小时，然后我会从里面选出一些人经常跟我交流。
+
+其实难度很大，我们就纯粹聊乱七八糟的，但大家没那么熟，不知道聊啥，而且两个技术的人没什么可聊的。多数Leader不会这么做，因为是闲聊，不是聊工作，所以做了可能对我业务也没帮助。
+
+极客时间：那你聊完这100个P8有没有什么具体收获？
+
+毕玄：肯定会有，你只有聊过才会发现，有些人对一些问题其实是有思考的，然后你会觉得有些人其实挺有潜质去承担更大的事情。所以我以前也会跟下面的人说，我也需要你们跟下面更低一些级别的人聊。
+
+极客时间：手上的人有没有潜质是怎么判断的？
+
+毕玄：这个就只能主观，就是我看你对一件事情的想法是什么，这其实很重要的，因为不同级别的人，说白了，无非是他看问题的角度不一样。每一层都要有自己的角度，像有些很高层级，需要看经济发展的大势，我们做决策就不需要。但这点对很多人的挑战很大。
+
+极客时间：这个挑战是指什么？看问题的新角度很难训练？
+
+毕玄：因为你可能根本不觉得自己角度不够，就会导致你下的判断很有问题。
+
+为什么大家很多时候觉得老板不靠谱？觉得老板都在瞎做决定？是因为你觉得自己很专业，看问题的角度很对，但事实上老板他看到的角度可能比你更多，他另外的一个角度导致他做了那个决定，但这个角度你压根不知道，也不关心。
+
+但好的Leader是会讲这些的，阿里以前这点就做的很好。我会跟你讲我为什么做这个决定，我的考虑、出发点是什么，你可以不认可，这没关系，但是我至少已经告诉你了，所以你也就可以理解我为什么这样做这个决定，不会觉得我是闷头随便拍的。
+
+因为多数Leader做选择肯定是有原因的，肯定不是闷头，只是他愿不愿意跟你讲而已。很多就比较粗犷，我懒得跟你讲，你按照我要的做就好了，管我怎么想的。但这样反而对执行层面的影响会很大，如果员工理解了，其实执行的偏差度会小很多，虽然他内心可能还是不认可，但这就不重要了。
+
+
+
+
+
+　
+
+极客时间：所以作为Leader，团队人多了或者换到了新团队，一定要做好花精力了解手下人的准备，这一点是你的经验教训。还有什么吗？
+
+毕玄：后来我带的团队已经很大了，我发现大团队的Leader，更难的是排兵布阵的阵型问题，因为除了你，你团队的很多人都会面临这个挑战。
+
+我后来经常问手上的人，你觉得，理想中你团队的阵型应该是怎么样的，阵型里的那几个位置，就是向你汇报的那几个人，能放一个P几？
+
+如果你认为这个位置到顶能放一个P8，但是我觉得可以放个P10，这就完全不一样了，我得考虑一下是不是该把你换了，因为你限制了下面人的空间，阿里以前有句老话，P10带的团队可以都是P10，但P9带的可能就只能到9。
+
+包括招人也受这个影响，你能不能招到一个更好的人取决于你怎么给别人讲，这当然是画饼，但高级别画饼是很重要的，除了钱以外还得画饼。
+
+极客时间：这里能容纳什么级别的人核心考虑的是什么问题？人才的成本问题？
+
+毕玄：主要取决于价值，为什么我能容纳一个这么高级的人？是因为我做的事情对这家公司的价值是足够的，面临的挑战，需要很高级别的能力才能稳得住。跟评晋升是一个道理。
+
+这一点，很多人是很难想清楚的，他就觉得我招一个这样人够了。但我觉得应该招个更好的人，而且也完全可以招到。所以关键就看他到底怎么想，我坚定地认为一个Leader要做好，核心是先要对整个团队的方向有思考，你有自己的观点很重要。
+
+极客时间：为什么你会觉得“思考团队方向”对Leader来讲最重要？
+
+毕玄：因为能开始思考方向首先意味着他有基础知识的积累，另外是他会主动去想，很多人其实也不太想这个事的，不想承担这个责任。
+
+说实话很多人做到Leader的位置是可以不想的，上面说什么或者下面说什么，我就做，我不需要表达自己的观点，反正我是个执行者。这是最安全的Leader，因为没做好，要么是上面给他再发一个问题，要么是下面干活不靠谱。所有公司这样的Leader非常多。
+
+所以做Leader，你能不能想好负责的这一块儿，要走到哪里去？你可以跟我观点相悖，这都不重要，但关键你想过，并且有逻辑，那我觉得就可以了，这个人我觉得未来是有潜质的。
+
+我觉得，其他所有技能都是可以弥补的，但对方向的感知这个技能是很难被弥补的。如果你其他很强，但没有这个，我觉得你是不可能把团队带到一定高度的，没有前景，因为你不可能做创新，最多执行做得还可以。
+
+　
+
+
+
+　
+
+极客时间：好，聊了你对Leader的看法，也聊了如何成为管理者，以及管理者需要关注哪些方面。最后总结一下，一名Leader想带好团队的几大关键问题，你觉得是什么？
+
+毕玄：Leader就几件事，把方向定好，阵型布好，位置放好，另外当然是事情的跟进，还有一点整个团队的成长，就是人才培养问题，这也是我以前带团队没有做好的一点。
+
+如果成长问题没有解好的话，也没意思，因为最后可能是这个团队事情做得不错，不过成员没有得到成长，但最重要的其实是人，所以后来我们就会反过来看，只要这个团队的成员都成长了，通常来讲，事肯定就做成了。
+
+极客时间：人才培养你以前没做好？后来对怎么做好有新想法吗？
+
+毕玄：我以前没做什么，所以就做得不好。
+
+我们后来才觉得有些东西还是需要的，比如培训班什么的，尽管都觉得没有用，但也看你怎么开这个班，如果是讲怎么思考一些问题的就还可以，因为Leader可能最重要的就是训练他怎么看待问题，比如这个团队我们今年定这几个方向是为什么，现在团队面临的一些实际问题怎么思考，这些只能靠大家具体讨论。我们觉得这是可以训练一些Leader的，所以刻意培养还是很重要的。
+
+当然除了开班以外，更重要的就是你去安排这些人的位置。
+
+极客时间：安排人的位置，是刚刚讲的排兵布阵吗？
+
+毕玄：因为做项目其实是可以给有些人机会的。我们以前都太关注事情了，如果你太关注事情，就会以稳妥为主，在选人的时候肯定选最相信的人，以及你觉得最有可能做成功的人。
+
+这对Leader来讲是好的，他自己能拿到很好的结果，但是手下的人没有办法成长。这种Leader是会把下面人全用废的。
+
+极客时间：但一家公司肯定也有这种人。
+
+毕玄：很多的。大家会说你是踩着一片人的尸骨走上了巅峰，但他确实走上去了，其他人也没法说什么，而且公司很多时候觉得也可以接受，也会给很高的评价，因为他通常是更能拿到结果的人。这就要他自己怎么看。
+
+但这种人总体不是那么受欢迎的，因为他其实是没有团队的，尤其如果他的团队要去面临不同挑战的时候，这种人就很难，没有人愿意跟他，而且他也很难说每次都来一波新的人用，这也很难。
+
+
+
+
+
+　
+
+极客时间：作为Leader你觉得最需要关注的是人，那在人才培养上，你有什么自己觉得很好用的方法吗？
+
+毕玄：人才的培养体系这个事情，阿里有个人讲的特别好，就是Lucy（彭蕾），她绝对是这方面的绝顶高手。做支付宝总裁前，Lucy有一段时间是集团的首席人才官，我们听她讲过一堂课，冲击太大了，对大家后来带团队都有很大影响。
+
+当时她讲一个团队的核心资产是什么？不是大家认为的代码库，也不是机器什么的，其实是你手上的这帮人。所以她要求每个月或者每个季度，Leader应该做一份人才的资产负债表，就像做财务报表一样。这个报表里要体现出你这个团队里的人才是在亏损还是在盈利。
+
+亏损盈利就是指，比如说你作为Leader，认为团队里有5个人必须关注他的发展，那这5个重点人才的职业生涯发展是向上的，还是平的，还是向下的。向上就是盈利，向下就是亏损。
+
+极客时间：这个人才表是怎么具体操作的，可以详细讲讲吗？
+
+毕玄：首先你要盘点你现有的人，另外还要盘点你需要吸引的人的能力，最后你年度下来给一个报表，看看今年你在整个团队的人才资产上到底是盈利的还是亏损的。说实话按这个，多数Leader估计都得挂。
+
+极客时间：算完人才帐就很清晰了，但感觉这个工作量挺大的？具体操作起来效果怎么样？
+
+毕玄：对，Lucy这张表真的很好，我们都觉得应该做，但大家因为业务精力各种原因没有做好。我后来就每年问我团队很核心的人那个问题，过去一年到底对你的职业生涯是向上、向下还是平的，你会写进简历吗？
+
+但技术线Leader确实特别难做，多数技术线Leader是被硬推上去的，他本身不想管人，但你真的要做好人才这件事，意味着你在人的身上要花费非常大的精力，要和很多人聊天。
+
+业务线里更难，因为业务线里更直观，就是关注指标，比如说我只看今天的销售额有没有做到，才不管你们这帮人有没有成长，而且有时候想关注也没精力。所以我们可以理解。
+
+极客时间：那你的下属如果是重点人才，他想离职，你会留吗？
+
+毕玄：我从来不留人，一般都是向我提离职，我就同意了。
+
+因为开始的时候我会讲清楚我不留人，大家都比较熟，你提了我相信你肯定是经过考虑的，而且向我汇报的人级别不会太低，你作为一个这么高级别的人，如果想过了外面，基本上就会离职，至少在我接触的人里都是这样。因为你的心一旦想过，就太难阻挡了，我再留你没有任何必要，所以我从来不留，但我的HR有时候很不爽，他们会去帮忙留。
+
+但我是会聊的，看看你是怎么想的，无非是你认为对自己的职业生涯成长更好就可以了，也不需要我认为，所以我都只问为什么你觉得这个选择对你的职业生涯更好？如果你觉得是，那不纠结，如果你想了一下觉得好像也不是，要留下来，那你就留好了。
+
+极客时间：对职业生涯的选择，你会给建议吗？
+
+毕玄：我会说我的考虑，但肯定是以你的判断为主，因为职业生涯这个东西说不清楚。
+
+极客时间：聊的时候，有没有人让你觉得他的想法其实不太理智？
+
+毕玄：很正常，这个跟你对趋势的判断有关系，很主观。
+
+　
+
+水友讨论区
+
+到这里今天的主题讨论就结束了，不知道你是否有启发。
+
+如何成为Leader？毕玄认为核心是解决对管理的认知问题、和人打交道的心态问题。
+
+一个Leader，毕玄总结需要做的就几件事，定方向、布阵、排兵、事情跟进，以及整个团队的人才培养，他认为想要成为一个好Leader，了解手上的人非常重要，他会周期性地问3个问题：
+
+
+你离开公司的时候，你会找一份什么工作？
+过去一年你觉得，对你的职业生涯是加分、减分还是持平，能不能写进简历？
+对团队的一些看法，觉得有没有什么问题？
+
+
+后来团队更大，他还会问手上的Leader，你觉得理想中你团队的阵型应该是怎么样的，阵型里的那几个位置能放P几？
+
+如果你现在是一个Leader，这几个问题你会怎么回答呢？如果你还没有开始带团队，其实在个人成长上，这几个问题也是非常好的复盘工具，甚至你也可以做一张自己各项技能的资产负债表，看看过去的大半年，哪些项是盈利的，总计是正还是负。
+
+欢迎在留言区写下你的回答，如果今天的内容你读完有收获，也欢迎分享给身边的朋友，一起讨论。
+
+下一讲我们会聊一聊有关做事的文化，下一讲见。
+
+拓展阅读
+
+之前毕玄就程序员的个人发展写过几篇文章：-
+1024，节日快乐的同时说说中年危机-
+“混”的中层们，你们的下一站是？
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/开篇词这一次，我们来采访毕玄.md

@@ -0,0 +1,61 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            开篇词 这一次，我们来采访毕玄
+                            你好，非常高兴能和你在《超级访谈：对话毕玄》专栏见面，我是编辑叶芊。
+
+你是不是很好奇，为什么这次要和毕玄对谈？答案很简单，因为这个人有一份神奇到独一档的职业经历。
+
+2002年大学生物系毕业后，他成为了一名做政府项目的小程序员，在小厂辗转了五年。到这里，看起来还没有什么太独特的，就是一个普通的非科班程序员。
+
+但就在小厂的第五年，他被称为国内 OSGi 第一人，07年年底顺势加入淘宝后，就开启了自己仿佛转岗无上限的成长之旅，你也可以简称——“开挂”。
+
+一进淘宝，他就负责HSF的设计和实现，在14年后的现在，HSF每天还都承担着百亿次以上的服务调用，是淘宝乃至阿里非常重要的中间件框架，但后来他居然跳去做了NoSQL数据库HBase的改进和落地，在接下来的2011年，他仿佛预测到了容器的技术浪潮，又转岗去负责淘宝私有云T4的设计和落地，比Docker都要早两年。
+
+但那之后他居然又从研发转到了运维，成为了一名运维工具研究员，顺带2013年做了广为外界所熟知的淘宝异地多活改造，之后丝滑过渡到了更大的集团级项目——云资源统一调度，同时还带着研发效能部门，做研发效能工具。19年他开始带视频云的业务团队，结果因为疫情视频领域爆火，部门备受瞩目，但下一年他却从阿里离开了。
+
+现在他创业快一年了，是一家做资源调度产品公司的CEO，据说天使轮已经融完了。
+
+
+
+这么看毕玄的职业经历，你说这个人，转岗也就转岗吧，方向判断得这么准，就像能预测下一个技术风口一样，关键是怎么还能做一个成一个？简直就是“谋事在人，成事也在人”的真实写照。
+
+现在你是不是对他的洞察力很佩服，是不是在想，如果能搞到他判断方向的技巧和成事经验，对你的帮助一定很大。
+
+正是因为这一点，我们从今年2月份开始筹备这个专栏，采访问题写了十几版，但因为档期和疫情几度差点夭折。每个月，我一边立一定能去采访的Flag，一边因为北京杭州两地的疫情心惊胆战，果不其然Flag倒了无数次。最终到7月份我们才挤出了三天，完成了一场共计13个小时的长谈，聊了100多个问题，终于，不负你的期待，我们挖到了这份来自毕玄的独家秘籍。
+
+于是，专栏最有代表性的“高手锦囊”模块也就此诞生，从个人成事、方向选择、团队带领、做事文化、架构修炼这5大方面，把他分析问题的思路和做事情的方法浓缩给你。
+
+
+
+当然想要把方法论化为己用，你还需要丰富的案例，这就是专栏前三章的作用了。
+
+在“初出茅庐”“江湖风云”“创业维艰”中，你将感受到这位技术大佬独特的人格魅力，这种魅力不仅来源于他判断方向的战略眼光和驾驭复杂多变局势的能力，还有他背后的有趣故事所带来的新维度、新认知、新启发。
+
+毕竟单看他的经历，我们可能觉得他是一个“平平无奇”的成功人士，基本没什么障碍，一路升级上去就成功了。但在看完一两讲他的神奇经历之后，你对他的印象一定会有一百八十度的大反转……
+
+简单举几个例子吧：
+
+
+面试，没写简历，也没答对几道题，他却进了淘宝？
+写第一个系统HSF，刚转正就差点把淘宝搞挂了？
+处理故障，充分锻炼了编程能力，他却说这对公司是个恶性循环？
+做异地多活被广为人知，他却说做大项目，千万不要塑造一个神？
+转到前景堪忧的运维团队，他表示团队价值问题自己也解决不了？
+集团级项目统一调度做成了，他说可能是因为时机？
+……
+
+
+基本上所有我们认为有点奇怪的现象，在采访的时候他都说“这很正常”，这句毕玄的口头禅也能算得上是这个专栏的小彩蛋了，如果你好奇，可以统计一下都出现在了哪里。
+
+所以如果要一句话介绍这个专栏，这并不是一位成功人士的回忆史，反而是一场20年踩坑经历的深度复盘，讲的是：一个很有个性的普通人，如何在互联网浪潮中辗转腾挪，找寻自己的发力点。当然等你看完，如果有其他想法，欢迎留言交流。
+
+另外，如果你对毕玄做的一些项目感兴趣，期待了解更多的技术细节和方案，也不妨看看文末的「拓展阅读」，希望对你有帮助！
+
+好啦，现在万事俱备，我们一起来认识下这位大神吧！
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/成事：技术人最大的问题就是情怀化.md

@@ -0,0 +1,209 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            成事：技术人最大的问题就是情怀化
+                            
+你好，我是叶芊。-
+　-
+从今天开始，“高手锦囊”板块的5场专题研讨即将展开，我们会从毕玄的具体工作经历出发，在“个人成事、方向选择、团队带领、做事文化、架构修炼”这5个方面，希望能总结出可供借鉴的分析思路和实操方法。-
+　-
+毕竟对于这样一位技术敏感度如此之高的大佬，仿佛总是能提前站在下一个技术风口上，他是如何分析技术方向的，又是如何在一次次技术浪潮中求得自己和团队发展的，如果能总结出这种方法论，相信对你一定有很大帮助。-
+　-
+今天我们先来对HSF做复盘，毕竟第一次总是印象深刻，对于第一个真正自己从0做的访问量巨大且核心的系统，又出了大故障，他总结了哪些成事方法呢？
+
+
+　-
+极客时间：复盘一下你进淘宝做HSF的过程，这是你做的第一个专业性要求高的系统，之前所有人都讲做一个网站，访问量从 200 万到1 个亿是不一样的，但没有人知道到底哪里不一样。经历过上线故障之后，你觉得大量级的系统到底是什么不一样？
+
+毕玄：这一次之后我就懂了，量级其实不重要，重要的是要求。一个要求非常高的系统跟其他系统的差别是什么。
+
+要求非常高的系统，核心是对整个系统的所有环节，你都要非常非常清楚。因为这是概率问题，你以前可能认为十万分之一的问题不会出现，但在一个大型系统里，它是必然会出现的。所以写一个小系统是容易的，写一个超大系统因为所有的概率问题都会爆发，对工程师的要求就变得非常非常高。
+
+以前流行一篇文章，你在浏览器敲了一个回车发生了什么？这个问题其实挑战很大，说实话，到现在也没有多少人能非常好地回答出这个问题，因为背后有非常多链条。
+
+你必须非常清楚你负责的那个部分从头到尾所有代码的细节，后来阿里对基础工程类的人都有这个要求，不能说我用了一个三方开源的东西，它出了故障，所以问题是它的，那当然不是，对我们来讲，都是你的故障。
+
+在这个阶段，对工程师的要求已经完全不一样了，不是说你写完一个功能就拉倒，是你要能把代码维持着，这个挑战就非常非常大了。
+
+极客时间：维持代码的成本，在开发之初也要考虑清楚。
+
+毕玄：对。一个要在生产环境跑很多年的系统，未来怎么可持续地发展，在设计阶段是非常重要的。如果你做一个系统，面对1个用户和面对1000万个用户，只跑一个星期和可能要跑10年，都有很大差别的。这就是我最后交付的成本。
+
+硬件也是一样，软硬件其实最终体现就是价格。我们看硬件，有些保修期很短，有些很长，有些寿命很长，有些寿命很短，决定了它背后的选择是差别很大的。当然，软件可能还做不到像硬件一样这么直接的映射，但差不多也是这个概念。
+
+极客时间：所以为了保障对代码的掌握程度，大厂一般都自己写？
+
+毕玄：如果过多用别人的东西，你是很难清楚掌握的，最好全部自己写，在出问题的关键时候，你可以迅速反应。当然你也不可能说一切都自己写，肯定会用到一些开源，所以我们会要求，你如果用任何开源的东西，对这个东西的所有代码也必须非常清楚，否则，在大规模系统里你一定会栽跟头。所以对大规模系统来讲，技术选型是很不一样的，包括对团队的要求也是。
+
+很多开源的东西，大家觉得外面很火，阿里为什么不引入？其实很简单，引入进来，阿里又没有一个专业的团队来维护，那最好不要引入，你还不如自己写算了。这样代价肯定是也有，但对公司来讲可以接受。这个就是认知。
+
+
+
+
+
+　
+
+极客时间：我们继续一个系统的技术要求这个话题聊，如果说量级不是核心重要的，那对开发者来说，是什么导致了系统的高要求？
+
+毕玄：其实本质是业务，你看现在的几个网站，业务要求的差别非常大，也奠定了他们背后技术难题的差别非常大，我后来接触了一些要求更高的公司对这一点的感受更强烈。
+
+淘宝你说以前要求高，当然也高，但是说实话还没那么高，因为淘宝出完一个故障，如果几分钟后能恢复，交易量是能恢复的，会冲高然后恢复。所以淘宝说实话出一次故障也就这样，能发生什么？所以出了再处理是可以的，如果还能快速处理，大家就觉得你很牛了。
+
+但像饿了么这种外卖公司，很大的挑战是他的系统在11点12点的时候不能出故障，关键是不能出，压根不能，这就不一样了，跟我们出之后再弥补差很多。
+
+极客时间：因为外卖的业务竞争太激烈了？
+
+毕玄：对，很简单你想，我饿了么跟美团打的这么辛苦，可能因为你们技术团队11点出一次故障，业务份额瞬间就变了，那还怎么玩，因为用户一定要点外卖，饿了么不能点，就会去美团点。包括当年滴滴跟快的的战争，快的背后是我们，当时我去快的呆了一段时间，处理各种问题，也是为了能让它更稳定，腾讯也派了大量工程师去滴滴。
+
+这个时候技术真的是关键，因为谁稳定，就决定了用户会倾向谁，当然钱的补贴很重要，但技术也很重要。所以这个阶段，稳定性，已经是这些公司的核心能力了，本身就已经成为业务了。
+
+这种对工程师的挑战非常非常大，因为一个不能出故障的系统是很难做的，但是如果说能接受出故障，给我1-5分钟的恢复时间，这两个系统的设计会有很大差别，因为出故障以后我可以想各种办法，但那个不能，我也很难回答。
+
+所以我们做其他系统就会越来越明白，有些系统其实不像大家想象的那么简单。当时还有个段子，因为淘宝做的比较好，12306总出问题，大家都说淘宝双十一都没事，把他交给淘宝不就行了吗？但你如果仔细了解一下，会发现这些系统其实不一样的。
+
+极客时间：什么不一样，可以展开讲讲吗？
+
+毕玄：12306这种是涉及民生类型的，像饿了么也可以认为涉及民生，包括共享单车都是，银行、金融这种就更不用说了。
+
+到民生这种，挑战是挺复杂的，12306交给淘宝也不好解决，因为它和淘宝最大的区别是库存。淘宝的库存是静态的，买一个商品有多少库存，减1就好了，比方说我能卖1000件，那我减就行，虽然是高并发但也没什么，排队就好了。但你看12306最复杂的就是库存。
+
+因为买一张火车票，从A站到B站中间有很多种可能性，是一个动态算库存的过程，但库存这个东西压力是最大的，还要动态算，淘宝都没想过这个问题该怎么解决，因为淘宝在库存上也很痛苦，但那也只是单品。
+
+极客时间：所以和大家想的不一样，民生相关的系统，像12306、银行，看着业务很简单，但背后是不能出问题。
+
+毕玄：对，包括以前我们觉得金融行业落后，像银行，你看看你们，做个变更简直了怎么这么难？后来我们懂了，如果我们是你们，估计也会变得那么严格，因为影响面是不一样的，银行只要哪一天钱取不出来，可能会立刻引发社会动荡，你说你是技术故障，别人可能都不信。
+
+淘宝说实话并没有影响民生，而且商业竞争还不到出了问题用户就去另一个的程度。像外卖、打车太明显了，某天你份额异常飙升，基本是因为你的竞争对手挂了，根本就不是你业务做得多好。
+
+现在，软件的核心系统对工程师的要求在直线上升，说实话新一代的互联网工程师是比我们更难的，因为我们有时间去成长，他们其实没有，上来就是必须做到这样。我们是出了无数次故障，然后慢慢学会的，知道每个地方是什么原因，但他们就真的太难了，因为没有机会。
+
+　
+
+
+
+　
+
+极客时间：你说新一代互联网工程师更难，为什么会产生这个差别？和以前相比，你觉得现在这一代工程师面对的新问题是什么？
+
+毕玄：现在软件的要求跟以前的软件有很多差别，以前AWS取了一个名字，我们觉得很土，但后来觉得这名字也还不错，AWS给现在的软件取了一个新的定义，叫Modern Application。
+
+如果大家去看以前的软件，一是相对来讲功能比较单一化，不会太复杂，现在大家要做的软件上来复杂度就比较高，软件要链接的东西更多。以前是我只实现一个功能，现在你看到的可能只是一个功能，但背后其实是N多功能叠加起来的，都是一个很复杂的公式，所以软件复杂度就很高。比如说外卖，背后涉及的链条非常长，软件写起来就很复杂的，不像以前我们很简单，这就是时代发展。
+
+第二，以前的软件都是有成长期的，因为成长期很长，它对稳定性、可用性的要求不会那么高，以前大家不能用，也能接受，不能用就不能用，我可以换人工。但现在不一样了。
+
+现在软件的成长周期太短了，在中国你从0做到1000万用户，以前要很多年，现在可能是几个月的事，这就完蛋了，淘宝当时能花一年来搞架构演进，现在的公司哪有这个时间，没等搞完他就倒闭了；而且这种倒闭就太冤了，我本来发展得很好，因为我发展得太好，用户量太大，系统撑不住，所以挂了，这简直了，发展不好挂了也就算了。
+
+但现在技术侧就会面临这个问题，你的成长时间非常短，商业竞争非常激烈。当年不是这样的，淘宝起来的时候有竞对吗？自从把eBay踢出去，至少在那几年是没有竞争对手的，所以，稳定性等等都不重要，把业务、功能各种都做好就行了。
+
+极客时间：所以还是回归到了业务、商业层面，当时如果淘宝有竞争对手，对业务和技术的态度会不一样？
+
+毕玄：我觉得很多都会不一样。但是现在中国不是这样了，现在你做了A，只要能起来一点点，你可能会发现中国瞬间诞生了100家做A的公司，那你要求的技术门槛就直接拔高了。
+
+说白了就是利润空间的问题，一个行业只要开始赚钱，在中国绝对会卷到死。在海外这点会好很多，因为海外看你已经赚了那么多钱，那我还是不要做这个行业了，他会觉得我的机会很少。但中国不会这么看，中国会觉得，哇！他那么赚钱，我也可以做。
+
+极客时间：不同时代的软件，以前就看业务，现在还要求技术门槛。
+
+毕玄：以前技术真的不是核心，对业务来讲，说实话一点都不重要。
+
+淘宝最早根本不认为技术有什么重要的，反正能用钱解决的，我全部用钱解决，技术最好不要干，最好全部是写业务代码做需求的。不要说我有一个团队是不做业务的，全部在研究什么基础技术，那完蛋了，因为这就是养人，而且这种人通常又比较贵，养一帮这种人都是成本。但现在不行。
+
+现在很多公司上来如果技术没有达到一定的分数线，可能业务都没机会做，就已经挂了。因为中国用户被训练出来了，对体验的要求非常高，中国用户点一下恨不得立刻下一页，如果还多要转几下，他就放弃了，太卷了，但海外不会。这些背后全是巨大的投入，不管是人员、还是IT成本。
+
+这就是现代，后来我们很认可AWS讲要跟原来区分开，当然它也是告诉你，为什么现在很多公司，尤其是初创还没有那么稳定的公司，应该用云，其实就是分数线。因为你用，至少一开始就一定达到了分数线，然后你可以更专注在业务上。但以前不存在这个问题。
+
+极客时间：系统的技术要求变高，之前和现代的界限，是什么时候开始的呢？
+
+毕玄：中国我觉得就是移动起来。在PC时代，你看竞争其实不是很激烈，那个时候互联网还没爆发，没让大家觉得做这行有多赚钱。当然还有更赚钱的，当然也不能做。然后，大家突然间发现做互联网是最赚钱的，中国肯定卷死，这是中国最痛苦的地方。
+
+极客时间：移动互联网起来的时候，大家都觉得怎么着做个5年10年的，但没有想到这么快，客户端没几年就发展到饱和了。
+
+毕玄：因为PC就很多年。
+
+极客时间：为什么移动时代会发展得这么快？
+
+毕玄：我觉得跟中国手机发展的比较好有关系，然后网络条件比较好，国外其实是因为网络太差，你想在印度点一下那么慢，那还是不要用了，手机也差。但中国这些基础设施太好了，基础设施真的是关键，基础设施越好，上面就越会爆发无数的可能。
+
+
+
+
+
+　
+
+极客时间：关于HSF前面聊了这么多，主要是超大系统对程序员开发能力上的要求，在具体的技术选型上，之前你也在很多文章中反思用OSGi是非常错误的决定。
+
+毕玄：对是的。
+
+极客时间：现在你再去做HSF的技术选型会有不同吗？
+
+毕玄：不会，我觉得还是错的。这是我后来总结的，技术的人最大的问题是太情怀化。
+
+我以前选择OSGi最大的出发点是什么？就是情怀。因为所有人都知道我出名是因为OSGi，很多人在我来了淘宝以后都问我：淘宝用OSGi吗？我说没用，这个对我这种技术人还是有点伤害。因为支付宝也用OSGi，我跟阿玺他们都很熟，他们用，我不用，他们又经常找我问问题，后来我就觉得那不行，淘宝也得用。这就是情怀，纯粹是情怀。
+
+很多技术人做一个决定，其实他的出发点就是不对的，他的出发点就是情怀。
+
+极客时间：但大家可能会举Linux的例子，很多做了最伟大技术的人，可能就是出于情怀。
+
+毕玄：但我觉得在公司的层面，肯定是不能那么干的。所有的公司都是一家商业公司，那商业公司里做的所有事情，确实应该要对这家公司意味着什么。
+
+所以关键是反思选择把原来的东西改造成基于OSGi的，对当时这家公司来讲，对客户、用户来讲，意味着什么？到底有没有帮助？是不是一个很好的长期发展选择？如果他的问题，你其实没有任何解决作用，那还不如以前，因为新方案一定会带来很多新的问题。
+
+很多技术人，做决定最大的问题就是情怀太美了。比如说很多架构师Leader他为什么做这件事，可能就是技术上觉得这个东西看着不爽，想把它改的更完美一点。技术人确实有这样的癖好，因为技术这玩意确实可以很完美化，我觉得这个架构看起来不好看，这个代码看起来可以写的更好。
+
+极客时间：但是从商业上看，把代码、架构改得更好看这些都是成本。
+
+毕玄：对，商业是一个妥协的问题，事实上，一个平台要做好，架构师最大的挑战就是做平衡。所以在阿里我们面试很多P8升P9的架构师，问的核心话题都是你在这一轮架构设计里面做过什么选择和平衡，这才是最难的，而不是你做了什么很好看的玩意，一个看起来很完美的架构，最后有可能对公司是极大的伤害。
+
+极客时间：这是业务上的考虑，是不是也有团队上的？因为后来听说你要做别的业务，但HSF这个项目用的技术栈又是OSGi，所以想托给其他人负责维护非常难？
+
+毕玄：是的，这个肯定有影响。因为你对整个团队的要求变高了，这很痛苦的，未来团队的招人等等都是大问题，包括团队的人出去以后，他们其实也会各种担心。
+
+后来我跟很多人聊，包括有技术情怀的，他觉得有个语言特别好，用这个可以写一个更好的、性能更高的东西，对这家公司会有很大帮助。这个出发点看起来没错，因为出发点是对工作业务有帮助。
+
+但这里没有考虑到一个问题，如果你离开了那个团队，这玩意谁能搞定？如果没有你在，就没人能接，那就是你给公司挖了一个坑，然后公司还不能把你怎么样，这不就是坑公司？
+
+所以很多时候讨论语言选择是一个最无聊的话题，因为语言的选择，事实上不是单一爱好的问题，是我站在公司整个层面上，包括人才储备上，做的综合判断，不是说我觉得这门语言多牛，这不重要，每门语言都有自己很适合的地方，否则它为什么活着呢？
+
+极客时间：你这么重视对公司、团队方面的考虑和权衡，在技术人里不是太常见，你是怎么意识到这一点的？是你在后面的项目经历里慢慢体会的？
+
+毕玄：这一点其实是我后面一个老板对我的影响，七公，就现在淘特的负责人。
+
+那一年我被提名P8P9的晋升，写完PPT他帮我看了一下，然后他说你这个PPT最大的问题就是没有讲清楚你做这个事情的意义是什么，就是技术的出发点。
+
+他说我技术层面当然没有问题，都讲的很好，但越高级别的人，越需要回答的问题是你为什么要干这件事情，而不是你怎么干这件事情，以及怎么解决里面各种各样的技术难题，这些是偏执行层面的，当然也需要，因为一家公司肯定有很多技术上非常难的事情需要人解决，但是更需要的是，有人去思考这家公司到底要做什么？为什么要做这件事？这是最大挑战。
+
+他那次跟我聊了之后，我一定程度上开窍了，后来我所有的技术规划都是以这为出发点。很多技术的人可能很难接受这个，但这就是你走向成熟化的必然。因为我们也能看到有些技术很神的，可能有纯粹的技术立项，这种确实很好，但关键是在中国的生存环境比较困难。
+
+
+
+　
+
+水友讨论区
+
+到这里今天的讨论就暂时结束了。理解了毕玄做选择的出发点，我们再回看之前他的所有转岗决定，背后的理由是清晰且一致的。
+
+在一个要求非常高的系统，你的敌人叫做墨菲定律，开发者需要具备更高的代码掌握程度，而且现代系统，因为业务复杂度和商业竞争度在不断提升，对开发者的要求也越来越高。
+
+但对技术人来说，最致命的障碍常常并不因为外界，而是因为自己，在技术选型上，想清楚你的出发点是最重要的，一名成熟的技术人需要从对公司、对客户/用户，以及对团队的各角度，想清楚自己做事的意义是什么。这是毕玄做事且能成事的底层逻辑。
+
+不知道你对今天讨论的哪个部分感兴趣，我还是列了几个讨论的话题：
+
+
+AWS说的Modern Application，作为身处其中的开发者，你有哪些感受呢？回顾自己做过的系统，要求是什么样的？你觉得挑战是什么？
+毕玄做事，他认为重要的是想清楚对公司/客户/用户来讲到底有没有帮助，是不是一个很好的长期发展选择。你做事的出发点是什么呢？关于技术人的情怀问题，你见过哪些坑？你有给团队/公司挖过坑吗？
+
+
+欢迎留言交流，聊聊自己当年（或者现在）炫技的那些事。
+
+下一讲我们聊一聊到底该如何思考技术演进方向，下一讲见。
+
+拓展阅读
+
+之前毕玄有自曝过自己因为技术情怀犯过一些错误：-
+技术人员的情结-
+我在系统设计上犯过的14个错
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/文化：你所在的团队，有多少人敢讲真话？.md

@@ -0,0 +1,326 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            文化：你所在的团队，有多少人敢讲真话？
+                            
+你好，我是叶芊。-
+　-
+今天我们要讨论的话题是文化，说“文化”这个词你可能会觉得很虚，那我们换个词——“做事风格”，这就和你们团队平时的协作习惯密切相关了。-
+　-
+做事风格，往小了讲，会影响团队成员对开会的认知、各成员的工作氛围，往大了讲会影响各部门间的协作成本，甚至公司人才培养的模式，乃至公司最根本的价值观。-
+　-
+如果你所在的团队或者公司，也在这些方面有疑问，那让我们一起进入今天的专题对谈，看看毕玄这个热衷解问题的人，会给出什么解法？
+
+
+　-
+极客时间：常听你讲蚂蚁的人才模式更好，为什么？
+
+毕玄：核心是文化不一样，蚂蚁是规划文化，淘宝是赛马文化，这就决定了两家公司有非常大的风格差异。淘宝的人很难适应蚂蚁，可能勉强能适应，但也不大适应，蚂蚁的人就更难适应淘宝。
+
+像淘宝的人喜欢折腾一些乱七八糟的事情，当然这几年更难，但以前会有人真的搞赛马，这就是淘宝的风格，跟腾讯类似，但腾讯不大一样的是它顶上那些是不大动的。
+
+极客时间：文化背后是什么？像这种做事风格应该也不是公司一开始就定了大家要这样。
+
+毕玄：我认为跟整个商业竞争有很大关系，就是在你的商业竞争面上，你到底认为技术在里面是什么地位？如果技术只是个支撑，那就一点都不重要了，如果技术就是你的竞争力，那你的看法就会变，会觉得技术人才的培养、存留都很重要。像蚂蚁更规划一些，也有是金融行业的原因。
+
+极客时间：在蚂蚁，技术就是业务竞争力，所以像架构师就会培养？
+
+毕玄：蚂蚁会刻意培养，他会有一个盘点，比如说你现在是负责这个系统的架构师，他如果觉得你有潜质负责整个业务板块，过一两年就会把你调岗，直接调去另外一个系统的团队里，这样你不就两个系统都熟了。
+
+蚂蚁很多大架构师都是这样培养出来的，有目的地调整人员组织结构。淘宝是没有组织培养的，所以这个事情就乱套了，只能靠项目，但靠项目就很难，大家都是被临时弄上去的，就会硬做。
+
+极客时间：直接从组织结构上调岗吗？
+
+毕玄：否则你没有机会的，很多人就是在一个系统干到死，他根本没有机会了解另外一个系统是怎么回事，他去哪了解？所以我们觉得，架构师这玩意儿是个组织问题。
+
+淘宝一致认为人才是靠野蛮生长出来的，你能成长就能成长起来，不能成长他觉得培养了你也成长不出来。
+
+这两种文化我们内部也讨论过，淘宝最终能长出来的人，当然确实不错，因为他是从一个非常复杂的环境出来的。这在公司前期还可以，因为野蛮生长总会长出来几个，只是不够多，但公司变大之后，业务多元化，要横向扩张，你面临的问题就需要一个厚的人才梯队池来解决，如果你不特意培养就没有了，公司就会断岗。
+
+阿里后来典型就是这个问题，我们想了一件什么事情，想找人派过去解决问题，就发现有点少。
+
+极客时间：什么时候开始发现有人才问题的？
+
+毕玄：后来选Leader都有这个问题，可能2017年就出现了，比如说要成立一个新的团队，想找一个什么样的人，我们一捞最后发现能选的就这几个人，而且他们进来这么多年，级别居然还没变，这就见鬼了。因为这些人很重要，但是又都没有得到晋升。
+
+　
+
+
+
+　
+
+极客时间：对于人才问题，当时你们怎么办的？也没有再去招人或者后面培养起来几个吗？
+
+毕玄：没有，这种我们没得选，说白了，我们还是会选信任的，都是这样。
+
+比如说架构师，如果已经有这样的架构师了，公司绝对不会冒险，他会选择我最信任的一帮人，一直做，除非这帮人全走。这也是我们一直反思的，阿里的架构师体系是一个巨大问题。
+
+走前我做的最后一个大项目就是阿里的集团上云，但我还是项目的总架构师，说实话我并不是很需要这个Title，而且我以前已经做过类似的大系统改造了，做这件事对我没有多大成长意义，所以何必呢，不如让一个有潜质的新人来承担这个位置。但是最后发现还是很难。
+
+极客时间：很难是因为什么，可以具体聊下吗？
+
+毕玄：因为一个大系统的架构，不是光有你，你下面还有很多系统的架构师，关键是这些人听不听你的。
+
+之前我们聊架构师的判断都是主观的，这个问题在当前阶段，我讲的所有方法，另外一个架构师可能不这么认为，他觉得我们应该用另外一个更漂亮的方法，但我可能偏务实，这样双方很容易产生冲突。所以这个大架构师能不能控制一批架构师的想法，让他们听你的，在大公司是一个巨大的挑战。
+
+一个新人上来，别人觉得你又没做过，不靠谱。像我是老人，我干过，你们都没干过有什么权利跟我说，我就能说：“我承认你说的挺好，但是你必须按我说的干。”
+
+所以架构师的培养为什么很难，尤其大架构师，因为他是以战培养出来的。
+
+极客时间：但战又很少？
+
+毕玄：对。而且有战的时候，公司在有选择的情况下不会故意培养，其实就把他用废了，因为他自己觉得已经没有任何意义了，而且干的很苦。这一点是我们以前很反对的。
+
+我们的想法是有选择的情况下，公司你也应该故意培养。有选择就是比如一个新人，一个老人，尽量用新人，不能说你觉得他以前干过，就继续让他干，关键他也不一定想干。
+
+像阿里双十一的大队长，这活都多少年了，还让他继续干，你说对他有什么成长意义，其实没有，对他来讲也不是个荣誉，他觉得没有任何意思。但公司觉得这个项目很重要，你干过而且成功了，所以继续让你干，是靠谱的。但这样新人一点机会都不会有，永远不会有机会。
+
+极客时间：那你们当时怎么办的，有没有什么解法？
+
+毕玄：我们当时就提议，公司其实不用纠结，你任命谁架构师，下面的人一定会听他的，因为我已经任命了这个人，下面就算叫的再凶，被任命的人也可以非常强势，实在不行就说我是大队长，你们就得听我的。
+
+极客时间：这样公司承担的风险更大，能给批吗？
+
+毕玄：换新人无非就是有点风险的，但是也能干，老人的好处无非是你可以相对控制风险，然后做好整件事情。
+
+但这也有方法的，你可以把老人放在后面。我以前就跟他们说，我不做这个总架构师，但我可以在背后支持，前面一定要推出一个新人，我可以坐在那张桌子上在背后支持他，只要是他说的，我都说都是对的。这个人只要这一战不会出太大的问题，其实他就起来了，成为了第二个。
+
+双十一大队长阿里不也换了好几轮，后面一直换，也没出什么大事。因为又不是真的你一个人能决定的，除非你在这个圈子里已经有极强的信任感了，你做的决定就是决定，但多数新人上去做的决定，很多时候根本不是决定，下面要经过N轮讨论的，所以你完全不用害怕。
+
+极客时间：但集团上云还是用的你，说明这个方案还是没过。那阿里后来架构师培养这个问题怎么办的？
+
+毕玄：阿里去年也想像蚂蚁一样搞，但关键问题是没法调，你觉得这个人有潜质成为大架构师，想让他今年做这个业务，明年做那个，下面的人会告诉你不行，这个人不能被调走。
+
+极客时间：业务架构师的调换为什么很难？有业务风险？
+
+毕玄：其实可以调，纯粹就是因为Leader，好不容易有个人能帮我顶住事，你把这个人给我调走了，那不就我自己顶了？但蚂蚁因为从上到下都贯穿了这个思想，他们是没有问题的。
+
+极客时间：到现在也没有一点改变？
+
+毕玄：在尝试，不过感觉很难，所以我说这是文化，一家公司的文化和基因是很难改变的。
+
+
+
+
+
+　
+
+极客时间：你现在新公司的文化，看你朋友圈讲希望成为一家“透明平等”、“大神型工作氛围”的公司，你是怎么想要定这几个？
+
+毕玄：这是我离开阿里最强的几点感受，就变成了我们公司的核心价值观，因为我觉得这就是关键。
+
+极客时间：先说透明平等，你定这条是想要什么？
+
+毕玄：这是奠定一家公司能不能做好决策，能不能让专业的人发挥价值。
+
+阿里以前坐一张桌子上开会的时候，没有人关注你是什么级别的高管，这跟我一毛钱关系没有，我只表达我的观点，因为我相信至少在我的领域，我比你更专业，所以我应该表达我想说的。至于你最后怎么做决定，只要你讲清楚为什么就可以，毕竟你是负责那个人，又不是我。
+
+如果谁一进去就跟别人说要这么干，我们肯定会问一句为什么？如果他不讲清楚，我们是绝对不会跟着干的，这就是以前。
+
+这个环境就非常良好，因为高层做决定要考虑非常多因素，你应该把你自己在专业角度上的看法全部告诉他，不是说他就要听你的，他会自己再综合判断，但他会讲他的理由和逻辑，你可以不认他的决定，但你至少认他为什么这么做决定。
+
+以前因为有这种氛围，我们都说阿里真的是一家非常牛的公司，因为做到这点非常难。
+
+极客时间：这种文化是怎么形成的？很难是因为常常老板自己先过不了这关？
+
+毕玄：很多老板会觉得我简直被你们挑战到极致。因为我以前给管理者培训，很多外企的人都问阿里为什么下属能挑战主管？我们说不就是这样的吗，大家本来是平等的，而且你下属在那个领域一定比你专业，他如果不比你专业，不很诡异吗？
+
+极客时间：但有些Leader可能会觉得我的经验比下属丰富，所以自己比下属更专业呢？
+
+毕玄：那就没法弄。但如果一个公司非常透明平等，其实，高层做决策的准确性会高很多，因为你听到了来自各方真实的声音，但如果环境不透明平等，这个桌子就会变。
+
+阿里后来有些人离开和这个是有些关系的。很多事情，你会觉得还是不要说好了，老板说什么就是什么，因为作为专业的人，你会觉得反正说了也从来没什么用，那干嘛说？有什么意义？这样，老板会越来越觉得我太明智、太聪明了，说什么都是对的，人都这样，肯定希望听到的是好话，我说一句你们每个人挑战我十句，很不爽的。但事实证明那样才是好的。
+
+你看阿里近两年不断讲，要保持自己是一家透明、平等的公司。但不断讲的时候，或多或少说明肯定已经在这个地方出现了问题，但光讲是很难改变的。
+
+以前的管理层，在宣布一个决定的时候，压力很大，很多人会挑战你很多问题，你得去思考怎么回答，总不能说我就这么决定，这样老板自己也会觉得很丢人，所以就会准备得非常充分来做宣讲。现在就没有太多人挑战，很好，你讲的都对。
+
+极客时间：准备不充分然后被人挑战的，你经历过吗？如果想塑造这种文化你觉得核心要解决的问题是什么？
+
+毕玄：这很正常，我就告诉他我确实没想到这点。
+
+这本质其实是心态问题，你能接受，就没有什么，被挑战了那又怎么样？很多人可能觉得作为Leader一定要什么都懂，或者是觉得损失了权威什么的。其实没有必要。
+
+透明、平等阿里这两年做的肯定没有以前好了，不过内网还是保持了一个比较好的环境，阿里的内网应该是各家做得最好的。什么都敢讲，而且我们当年比现在还敢讲，新人看不到太多很挑衅的发帖，老人很挑衅的。
+
+极客时间：大家都是实名，能有多挑衅？
+
+毕玄：以前马云任命博士（王坚）做集团CTO，马云发一个贴，下面一群人回帖反对，你想相当于是集团最大的头，说我要任命一个人，然后你们下面的人都跳出来说我不同意。这简直了，这就是以前的阿里，现在哪有多少人敢？
+
+　
+
+
+
+　
+
+极客时间：一个公司的价值观变化，比如说阿里，你觉得是因为什么？
+
+毕玄：很大的原因是加入这家公司的人的多元化。以前淘宝老人多，大家都这风格，我根本不在乎你是谁。但我们后来分析可能跟“安全感”有很大关系。
+
+老人为什么敢？是因为老人觉得自己很安全，因为我是对事，又不是对你这个人怎么样，所以就算我对你这样了，我相信我不可能因为这个被干掉，或者你敢对我有什么绩效上的不公平等等，我们相信绝对不会发生。
+
+但新人不敢，他可能以前在各种各样的公司，这么干一定会被人穿小鞋，那他就会先观察一下。再加上后来加入阿里的很多人，可能目的跟我们当年不一样，当年我也说不上，但我们肯定不是说来就是为了混两年拿股票，但新人有些是这样的，来镀金，股票能拿两年最好，拿到我就可以走了，但如果能再混一年多拿点，那更好。他当然不想挑战老板了，能让我混过去就可以了。
+
+极客时间：所以当公司到一定规模，价值观或者做事的文化很容易滑坡。
+
+毕玄：对，我也觉得，因为规模到后面，吸纳的人太多了，很难去严格挑，不现实。
+
+尽管阿里说我们要找同路人，但问题是你要的人太多了，能招进来都行，管他同不同路。像阿里后来自己也改了，说能同走一段的也行。
+
+现在大公司都这样，头条据说会稍微好一点，但我觉得是他们还没上市，阿里上市后有比较明显的分水岭，因为上市后股票能兑现，就意味着有钱了，大家加入的目标会有些改变。所以头条现在的状态应该最好，所有人目标完全一致，就是冲刺上市，但上完了估计也会碰到各种新的问题。
+
+极客时间：那这个问题怎么解？
+
+毕玄：我觉得很难解决。这种大环境一定会出现，可能就看你的比例。
+
+比如说作为团队Leader，在你的团队里，如果敢讲真话的人多，大家发现能挑战你而且好像也没被怎么样，那这个氛围就会被养成，大家也会被慢慢带过来。最怕敢讲真话的人变少，那就完蛋了，最后大家就一定都不讲了。
+
+这是个整体文化，如果大家都这风格，就不会觉得这有什么问题。所以最大的老板最关键，因为最大的老板如果不大能被挑战，那你看着吧，所有人立刻就是一个风向。
+
+因为阿里高层他们也不是不知道这些问题，但关键他们也觉得不好解。所有人都不知道该怎么解，这个问题涉及人，太复杂了。很多大公司到了一定规模，就跟人类的协作规模问题一样，你协作规模能突破多大。
+
+我们也希望看到一家更大规模的科技类型公司，因为现在全球的大部分科技公司都是这个规模，没有谁突破，一旦突破我们估计都不怕了。所以如果一家公司能透明、平等，那大家真的应该珍惜。
+
+　
+
+
+
+　
+
+极客时间：你公司的价值观除了“平等透明”，还有一个“大神型”工作氛围，这是想解决什么问题？
+
+毕玄：这句话其实是逍遥子讲的，他希望阿里也变成这样，大神型组织，而不是大咖型。
+
+大咖型是指因为你在这个位置，所以你说的都对。阿里有些团队这个现象特别突出，因为经常组织结构调整，那个人以前压根没干过这事，他调到那儿了，就变成了权威。像我以前不做音视频，后来成了视频云的Leader，我就成了音视频技术晋升委员会P8P9的评委，我说这合理吗，难道不应该找一个专业的人来吗？不能因为我是Leader所以我就专业了。这就是典型。
+
+大神型是指因为他专业，所以应该听他的意见。当然还是一样，最后的决策是另外一回事，是个综合判断，但我们要尊重大神，他更知道你讲的那个天花板是真的还是假的。
+
+极客时间：但很多公司可能就是那个位置上的人说了算。
+
+毕玄：因为他在那个位置，就会有很强的信心，我调到这个位置，我就比你们都懂，就会觉得下面专业的人提的都不靠谱。
+
+极客时间：或者我必须得表现的比你们都懂？
+
+毕玄：也有可能，那就是他没有安全感，特别在乎自己的权威。这种对一家公司，尤其技术公司就非常要命。
+
+极客时间：为了维护公司这样透明、平等、大神的文化，你有没有什么具体的措施？
+
+毕玄：只能看平时做事了。像我现在的公司会强调如果有人让我们做不了透明、平等，不管你是谁，不管什么原因，都会开掉。
+
+其实这取决于公司怎么捍卫你的价值观。为什么大家都觉得阿里以前是一家特别有价值观的公司，说白了就是下手够狠，只要出现就开掉，那所有人就懂了，有些东西真的是不能碰，碰了真的会死，不管是谁，不管是什么职位。
+
+极客时间：公司大了之后，直接开掉也可以吗？
+
+毕玄：也可以，只是很多人觉得好像缺了谁会发生什么。其实不会的。
+
+但后来的人就不大敢，会有各种考虑，会不会对我的业务短期有影响等等各种各样的，所以有些事情发生，就会导致整体价值观的作用大幅下降。
+
+极客时间：什么时候感觉价值观的作用下降了？一些奖罚？
+
+毕玄：对，这种类似的，因为大家都会关注。一个公司想守卫文化要付出很大代价，因为更多是靠惩罚来体现的，光喊大家肯定是不信的，只有处罚，而且处罚一定要够狠。所以文化价值观其实是公司的底线，如果不是底线，就不要把它列进去。
+
+　
+
+
+
+　
+
+极客时间：这种下狠手做处罚，是你之前说的“做正确的事”吗？
+
+毕玄：那不一样。“正确地做事”和“做正确的事”大公司会比较严重。
+
+比如说我是一个业务团队，为这个业务要做什么事情，但可能像财务、法务、安全团队等等会上来就告诉你，这个事有风险，最好不要干，这叫他们在“正确地做事”，因为站在他的角度他是对的。
+
+但这不是“做正确的事”，为什么大公司开会都很痛苦？大家觉得根本不在一条船？很多团队纯粹站在自己的角度，而且说的还没有办法被反驳，所以我们做业务的都很恼火，你老要面对一堆不背业务责任的横向部门给你提的建议，但是他们说的确实我也承认都是对的，但这就很恶心了。
+
+极客时间：我也不是搞你心态，我是真的在给你提我非常专业的建议。
+
+毕玄：对，站在他专业的角度，他觉得你这样做对公司会造成风险，所以他是正确的。
+
+但我作为业务方，承担了所有业务压力和责任，说实话，你们这些团队不是来上就告诉我不能干，是告诉我站在你的专业角度，你觉得怎样能干。比如说有法务风险，你要讲有什么方法避免或者怎么变成合规，但他怕这样说了他有风险。
+
+但你上来就告诉我什么都不能干，那我怎么让业务做得更好，我做不了，要不你们来干业务？我要的是解法，这才叫做正确的事，大家是在一条船上的。
+
+极客时间：这个问题怎么处理？
+
+毕玄：处理不了。有些人的风格是做正确的事，只要这个事对公司有帮助就做，不在乎比如能获得什么利益，或者有什么风险，这都不重要，大家的目标是一致的。
+
+但有些人的目标是，我能很好地在公司活下去就可以了，至于其他的我不关心。从人性上来讲，你是可以理解这些部门为什么要这样的，他是我不做错就行了。
+
+极客时间：所有大公司都一定会出现的？还是说因为公司文化？
+
+毕玄：我觉得大公司都会，但跟透明、平等一样，关键看怎么保持比例。
+
+
+
+
+
+　
+
+极客时间：除了做事的风格，我还有一点比较好奇，开会，你是怎么看的？
+
+毕玄：开会是没有办法的，做Leader我从头到尾都在开会，根本不再干别的，这很正常，因为很多横向的团队协作都需要你，调动资源各方面的。
+
+极客时间：有哪些你不参加吗？比如不同类型的会，信息同步的、问题讨论的、进度讨论的。
+
+毕玄：我一般很少开纯粹进度跟进这种没太大意义的会，太浪费大家时间了，你的进展我有很多办法知道的，不管在系统上，还是一个简单的周报，其实你写几句就可以了，我就知道大概情况了。
+
+极客时间：那有例会吗？
+
+毕玄：我们一般双周会开周会，通常一个多小时，更多是用来跟大家分享一些感受，或者同步大家不知道的公司上层的一些信息，如果有问题，大家就碰一下，如果没有问题就不要说，就结束了。
+
+我们开会最重要的基调，就是为了解决问题，还有同步信息。所以周会很多人很轻松，你不用汇报进度，当然有可能我会直接问你，一种是我觉得很有问题的，一种是想借机夸一下的。
+
+极客时间：那你们会有讨论方向或者规划的这种会吗？
+
+毕玄：但说实话我觉得很多都没有意义，因为不存在说什么几十个人讨论一个问题，这就不用讨论了，因为不会有任何结果的。
+
+我们可能刚开始的规划会有讨论，但规划这个东西在开会之前，主导的人就是Leader他自己，肯定是有想法的，只是想让大家充分发表一下而已，所以这种我们叫同步会，就是我来告诉你我的决定和理由是什么，你们知道就行了，因为还是需要团队都知道今年核心的目标是什么、为什么要这么做，这种其实要花一些时间。
+
+极客时间：所以是开之前基本已经有一个决定了，不会什么都没有然后所有人去讨论问题？
+
+毕玄：如果不解决问题，这种会就不要开，同步信息有很多方法，群里发一下就好了，干嘛要在这里。
+
+以前逍遥子很搞笑的，因为给他汇报多数不是同步信息，肯定是希望他帮忙解决个什么问题，所以老逍说看其他人的PPT，他都是翻到最后两页，因为最后两页才是关键，前面全都是废话。
+
+所以Leader是干嘛的？Leader是帮你解决问题的，其实他是你的资源，有些人向上管理做得很好，能把Leader用得很惨，这种人非常牛，是好下属。我以前的下属都很擅长这个，因为像进度和执行都是他们应该把握好的，我除了能解决问题还能干啥，我也干不了啥了。
+
+极客时间：你主要会提供哪些资源？
+
+毕玄：很多都是偏横向的团队协调，另外有些可能是他自己很难判断到底要往哪走，比如一个决定他要怎么做，这种你告诉他你自己会怎么做就好，剩下他可以自己做。
+
+大家对你的诉求肯定就是帮我解决问题，如果你解决不了，你就说解决不了，其实没什么的，很多Leader不愿意说，觉得我一定得帮助他解决，但很多确实不是你能解决的，因为大公司有些问题就是很难解决，很尴尬。
+
+
+
+　
+
+水友讨论区
+
+到这里关于“做事风格”的主题讨论就结束了，小话题比较多，所以聊的也稍微散一点，我们简单总结一下。
+
+
+人才培养：本质是从商业竞争面上看专业人才是什么地位？支撑VS竞争力
+工作氛围：公司能不能做好决策的基石？平等透明VS老板都对
+地位态度：专业的人才能不能发挥价值？大神型VS大咖型
+团队协作：各团队一起能不能做成事关键看比例？正确地做事VS做正确的事
+开会风格：开会是不可避免的但开会的基调是什么？讨论/同步VS解决问题
+
+
+至于解决方案，很可惜，涉及人的很多问题可能就是没有解法，关键看公司的想法，从公司对一些问题的具体做法里分析一下站在哪一方。
+
+毕玄后来也在朋友圈说：“规则对每个人的影响差别可能很大，所以要统一很难，只能是宏观层面的ROI选择，创业了的第一感受如果不计代价，很多决定并不难做，但事实不是这样。”
+
+不知道你对今天对谈的哪个部分比较有感触，欢迎在留言区留言参与讨论。
+
+不过别灰心，下一讲我们会聊一聊“架构师”这个很多程序员向往的职业，而且会有可实操的方法论哦，下一讲见。
+
+拓展阅读
+
+当时毕玄总结自己的2021年写了一次复盘，和公司文化相关：2021最大的几点感受
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/方向：技术演进，到底该怎么思考未来？.md

@@ -0,0 +1,244 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            方向：技术演进，到底该怎么思考未来？
+                            
+你好，我是叶芊。-
+　-
+欢迎来到技术视野的研讨主题，相信你一定非常期待，毕竟在当年阿里技术牛人辈出的时候，毕玄都是公认的技术方向感非常好，做4个方向最少能命中3个的那种。-
+　-
+其实他自己也非常清楚这是他的个人优势，后来写离职复盘的时候他说：“我认为程序员的价值关键体现在作品上，作品里很重要的一点是对业务、技术趋势的判断，希望作为程序员的大伙，都能有机会打造一款世界级的作品，去为技术圈的发展做出贡献。”-
+　-
+那他到底是怎么培养技术敏锐度的？话不多说，我们开始今天的对谈。
+
+
+　-
+极客时间：你对技术方向的判断力，经过了很多项目的检验，很多人公认你的方向感好。前面聊做决策的时候，你也提到Leader需要赌未来，带团队你也会团队成员讲清楚未来的方向和规划。这种判断力怎么形成的？或者说有没有什么？
+
+毕玄：方法论？
+
+极客时间：对，因为大家都喜欢，也都期待。
+
+毕玄：但真的没有方法论。
+
+极客时间：或者说技术敏感度？
+
+毕玄：我们觉得真的很难培养。以前我们就想过怎么培养大家对一个事情的判断，但这是个走势问题，未来可难说了，谁也判断不了。我们后来总结最重要的可能是你要去想。
+
+很多人其实从来没有想过未来的走向，就像技术，未来会走向什么？一般觉得什么最火就是了。比如说从SOA，到服务化、微服务，到Service Mesh，这是个历程，我们以前经常问很多人：你对这个历程怎么看？每个阶段到底有什么区别？
+
+我问过很多人，自己也被问得很尬，因为回答不了。比如请问我们07年到09年做的服务化，跟现在讲的微服务到底区别在哪？没有人回答的出来，那说明这根本是个瞎扯的词，不就是概念嘛，为了卖个概念忽悠人。包括Service Mesh，很多人各有各的看法，我觉得是什么看法不重要，我们最怕的是没有看法的人，但是你追问他为什么好？如果回答因为很火，就简直是瞎扯。
+
+极客时间：既然没有培养技术方向判断力的方法论，那别人说一个技术是颠覆，判断他瞎扯和不是瞎扯，你的方法是什么？
+
+毕玄：关键依旧是那一点，你觉得这个新东西的价值到底是什么？相比以前带来了什么变化？
+
+极客时间：新东西的价值怎么分析呢？每个新东西出来，看它技术演进背后的那个推动力是不是一致的？
+
+毕玄：对，以前在中间件的时候大家聊过这个话题，纯粹的技术演进到底怎么思考未来，以史为鉴是最重要的，但每个都不一样。
+
+极客时间：是每个公司不一样，还是说每个技术的推动力不一样？可以举个具体例子说下吗？
+
+毕玄：跟公司关系不大，主要看这个技术怎么往前走。
+
+我们经常举例大数据，因为大数据特别明显，从Hadoop，到Spark，到Flink，基本可以认为是三代。最关键的是你去看，为什么大数据会有这三代的演进？是因为它们都解决了用户对这玩意儿的核心诉求，如果这个诉求归拢到一起还是一样的，那就好办了。那用户对这几个大数据软件的核心诉求是什么？
+
+最核心的诉求是算更快。做一个大数据分析，想越快拿到结果越好，这就是我们的诉求。
+
+Hadoop解决了什么问题？Hadoop解决了0到1的问题，以前没有一个大数据的东西，Google发了一篇论文，然后Hadoop做了一个开源版的实现有了0到1，所以它一定会很成功。当然那个时候也不只有它，却是它成功了，这就有很多因素，比如说最重要的是大厂的支持，因为Hadoop是Facebook等等大力去推，这是不一样的。
+
+所以Hadoop解决能算出来，但有点慢；Spark解决的是我通过架构改造，让你整个具备了算更快的能力；Flink就更快，因为已经实时化了。你看它的技术演进，其实就是围绕了怎么解决掉客户的痛点，然后通过技术层面的架构改造来完成这个事情，当然这其中也有技术下面的基础设施成熟化的背景。
+
+包括中间件，回顾一下这些年中间件的发展，过去为什么会有几次迭代？几次迭代解决的都是什么问题？那我们认为肯定都是解决了一个痛点。
+
+痛点是要挖出来的，你围绕那个痛点去想，技术现在有没有可能把这个痛点往前推进一代产生很大的改变，你的新东西要解得更好，而不是小修小补。如果有，那我认，那就是技术真正的变革，而不是造了个概念。
+
+很多人觉得自己做的是新一代，我们就问相比上一代，用户在这一代里碰到的什么问题，你帮他彻底解掉了？
+
+极客时间：第一步想清楚用户的问题是什么，第二步想具体怎么去解这个问题，解决方案感觉也很难想。
+
+毕玄：技术演进本来就需要很多年，因为技术的下一代是很难想出来的，可能需要时机。数据库从关系到分布式走了多少年，理论上方向提了无数年，但直到现在才算是逐渐有了东西。现在数据库又在说要从OLTP、OLAP走向HTAP，这是更新一代，因为这也是用户的诉求，他们在不断往前推进。
+
+以前很多团队总纠结要不要硬造一个概念说我们现在做的是新一代，但是如果不到时机，其实没关系，你就维护着，只是很多人觉得维护没有什么价值。但你们造概念，公司更不会认，外面有可能被你忽悠。
+
+极客时间：但很多公司都会强调，技术人员要具备一定的影响力。
+
+毕玄：千万不要为了做影响力而做影响力。反正在我的评判里，这种我是绝对不会认的。我先只看你对公司业务的影响，然后如果你的方案确实在这个技术领域具备领先性，我才认为你有影响力。
+
+因为影响力是很容易培养的，你有了结果，也有贡献，做的方法也具备引领性，说实话，剩下的只要炒作包装一下就可以，如果你的公司影响力足够大，你想成为什么都可以，但前提都是你自己得有足够的实力，等你做到了，影响力什么的都是很自然的过程。
+
+
+
+
+
+　
+
+极客时间：怎么判断是彻底解了还是小修小补呢？既然每个技术背后的推动力不一样，我们再看几个技术。比如说服务化、微服务，这个核心诉求到底是什么？开始阿里做服务化是为了去解什么问题？
+
+毕玄：以前做服务化，核心要解的问题有两个。
+
+第一，要解决系统的水平伸缩能力的问题，因为服务化了以后，说白了你的每个应用，每个系统，要承担的责任变少了，所以伸缩性就能变得很强。
+
+第二个服务化的核心问题其实是研发协作的问题。以前100人开发一个系统，大家都没有分工的，我接了一个需求，要改哪我就从头到尾全改，这个时候有可能会出现冲突，因为可能每个人都在改同一个地方，大家合并代码的时候就非常痛苦，效率很低。
+
+服务化有分工了，你就改这块儿，他就改那块儿，当然这也增加了协作成本，但是它毕竟能让100人甚至上千人的研发团队可以并行做下去，这一点也跟AWS说的Modern Application有关，现代软件变得更复杂了，做任何软件上来就是一帮人，你必须考虑到一帮人协作的问题。
+
+极客时间：“协作”这一点感觉比较少讲。
+
+毕玄：我们当年其实也没有想到是用来解这个问题的。这是Jeff Dean在斯坦福讲Google技术演进的时候说的，Google做服务化的核心是为了具备千人以上的研发协作能力，这看问题的角度就比我们强太多。
+
+当时我们主要想的前一个，而且我们还是被逼的，因为不做服务化，就加不了机器，业务就崩盘了。
+
+虽然当时100多人研发同一个系统已经很痛苦了，但是我们没有想到服务化其实是用来解协作的，是做完才发现解掉了，后来看到Google说自己做服务化的核心目标是协作，我们觉得哇你讲得有道理，我们也加上了这一句（笑）。
+
+你看，服务化当年最重要是为了解这些问题，那微服务，请问跟服务化相比到底解了什么问题？
+
+服务化现在留下的核心问题是粒度，一个服务的粒度是主观的，架构想切成多大粒度就多大粒度，但这是有问题的；还有服务里面，比如说一个应用背后依赖了100个服务，到底哪些服务是核心路径是必须依赖的？现在都是靠人来控制的。
+
+除非你说服务化的新一代可以解决这两个问题，那才是革命性的。但现在做不到，说什么微服务，他们就编吧，可能觉得服务化这么多年没发展也不大好，总得编个新的。
+
+极客时间：微服务这个概念刚出来的时候不是很好理解，之前有人开玩笑解释为什么要做微服务，一般就是因为公司人有点冗余了。
+
+毕玄：所以以前很多小公司问要不要做，我们都说你做个啥，一个系统多爽，开发效率最高，分布式会带来很多问题，包括对研发能力都是巨大的挑战。只是看起来技术不值得吹，觉得技术很烂什么的，当然这不重要，对业务来讲这都不重要。有些人就会这样，想挑战技术难度，觉得这种才叫复杂度，其实不是。
+
+极客时间：但这种对技术难度的认知在技术团队里应该很普遍？
+
+毕玄：很正常，因为技术的人都是有梦想的，梦想用一个很先进的技术去做一件事情。
+
+但关键是在现今阶段，对公司来讲没有任何意义，所有公司不是不关注技术创新，只是出发点都是我到底面临什么问题。所以，这个问题除非你有一个创新的解法，可以比以前解得更好，那可以的，不能说你纯粹在外面看到一个很创新的玩意儿，一定要在公司用上，这就像拿着锤子找钉子。
+
+而且很多人想用新语言、新框架，因为理论上来讲，这对他的职业路径可能更友好，否则他出去不好找工作。
+
+　
+
+
+
+　
+
+极客时间：前面聊了大数据、服务化，现在最火的是云原生，这个技术方向我们也聊一聊，你觉得技术演进到云，本质是因为什么？云的下一步是什么？
+
+毕玄：CloudNative其实是个分布式，无非是原来搭建分布式的方法，现在变成基于云去搭建，这是颠覆我是认的，像新公司不需要投人了，都是云帮你搞定。之前从单体到分布式的架构是个必然，但现在分布式再走向哪里就说不清楚。
+
+极客时间：容器呢？这个技术演进背后的推动力是什么？
+
+毕玄：从虚拟化到容器化是革命性进步，这解决了什么问题？虚拟化无非解的问题就是怎么让一台机器能跑更多东西，容器化解的是我会跑更多。
+
+极客时间：所以全是资源的利用？
+
+毕玄：对，所以我们认为，容器就是个运行单位，而这个运行单位不一定叫容器，可能有个更小的运行单位。所以阿里后来在做轻量级容器等等方向的探索，包括Serverless一定程度你可以认为就是一个更小粒度的运行单位，这叫未来，是一个技术趋势，其实它一直都在解同一个问题，只不过比前一代解得更好一点。
+
+极客时间：Serverless这个新方向可以多说一点吗？对资源利用率这个问题，它彻底解决的点是什么？小厂完全不用买设备？
+
+毕玄：肯定不用买了，而且Serverless是真正的只有用了才要付钱。
+
+比如我的业务现在没有请求量就不用付费，请求量来了就只付那一点，但现在我们是按买的机器付钱，我可能现在根本没用，但还是要付钱。如果哪家云厂商敢说能按请求量付钱，那背后是不是Serverless我们都不在乎了，能这么牛的话，成本会省非常多，那所有都颠覆了。
+
+极客时间：Serverless面临的核心难题是什么？
+
+毕玄：主要是弹性的速度。比如Serverless我要拉起一个系统，这不是几秒就能拉得起来的，但对在线业务来讲，你不可能点一下几秒都出不来，大家能接受的都是几毫秒。所以Serverless都只是拿来做一些像计算这种后期的事情，以前可能是一些离线的事情，都是对响应时间可以忍受的。
+
+Serverless也许是未来，但还比较长远，现在非常不成熟，只是个补充方案，就很尴尬。
+
+极客时间：那一个技术，什么程度才算成熟？
+
+毕玄：所有的技术如果想颠覆，必须进入核心业务。现在没有完全基于Serverless这种新理念来构造的在线业务的技术框架，因为在线业务对稳定性是至高要求，而且它完全不可预测。
+
+尽管AWS推了无数年，一直希望能推进到一个全新的技术框架，阿里以前也想推，因为Serverless对云厂商来讲并不是坏事，如果真能做到，大家肯定都来用了，但很难，从技术上来讲目前真的做不到，这是最极致的弹性。
+
+极客时间：在资源利用这个方向，除了Serverless，有别的方案吗？
+
+毕玄：就是混部，现在混部到CPU层面了，大数据和在线其实都是CPU层面的，所以在离线的统一调度是这个阶段我们可以做的，能把利用率提高的一个很落地的方案。
+
+极客时间：调度的难题是什么？
+
+毕玄：之后最关键的是看GPU、FPGA这些能不能做好。
+
+调度这个事，其实阿里最早很多高管都有这个梦想，博士成立阿里云的时候提出云的实际表现是统一存储和统一调度，他认为云的核心是可以把所有的机器像一台机器用，这就是统一调度。这个思想最早提出的应该是Google。
+
+Google很早有篇文章叫《The Datacenter as a Computer》，一个数据中心像一台机器，这效率肯定是最高的，事实上现在也还做不到。Borg的思路是把CPU尽可能当一台机器用，但内存还不行，比如A机器现在空了1G，B机器有2G，但你不能说用户现在有3G可以用，这个真做不到，因为内存有时延的问题，在单机时延非常低，一旦跨了网络，但网络已经是光速了，这是物理决定的，就很难。
+
+据说Google想探索这个方向，因为Google近两年把这篇文章改了一下，叫《The Datacenters as a computer》，这简直颠覆了我们的想象。
+
+极客时间：Datacenters？跨地的那种？
+
+毕玄：对，跨地数据中心像一台机器，我们连一个都没实现，你已经开始提下一个概念了，我们没法跟你玩。
+
+
+
+
+
+　
+
+极客时间：好，我们前面聊了如何分析技术演进的趋势，大概判断趋势之后，大家更关心的是在这波技术浪潮里自己能做什么。比方说现在所有人都知道云是趋势，有云了，基础设施会更集中在一批人手里。
+
+毕玄：对，肯定是这样。
+
+极客时间：那很多人在小厂，会担心自己之后的职业发展甚至岗位会受影响，怎么办？
+
+毕玄：纯基础技术，像计算、存储、网络等等这种IaaS层面的，基本会收拢到几大云厂商手里，如果你要做这种技术，没有别的选择，加入这些厂商好了。
+
+你看创业，很少有人说我要创业做IaaS、要做计算，不可能的，这是需要更大规模效应的生意，为什么小的云厂商越来越难，因为只有你服务器规模到了多少万台的时候，才可能实现盈利，前期投入真的太大了。
+
+但在IaaS之上应该会诞生很多垂直的PaaS，也是做技术的，但这些反而不在大厂手上，全都在一些创业公司手上，这其实就是美国的现状。然后PaaS更上面是做业务的。所以看你自己想怎么走，去相应的公司就好了。真正喜欢做计算、存储、网络的同学其实很少的。
+
+极客时间：很少是为什么？
+
+毕玄：因为计算、存储、网络是个非常非常专业的领域，都是做虚拟化、计算资源这些东西，多数人根本就没有触及到这个领域，做的最多是PaaS，比如中间件、框架这些，而且未来外面会有好多家PaaS，空间是会越来越大的，不会越来越小。
+
+极客时间：就现在的行业发展进度看，基础技术逐步商业化了，很多人创业做PaaS，包括阿里很多也都拿出来卖了，这个改变是行业的进步吗？对其它公司，对其他团队同学也可以参考？
+
+毕玄：对团队同学的话，我觉得很难说。
+
+极客时间：为什么，这样不是能更好地专注研究技术了吗？毕竟商业化了，团队的业务目标就是要不断追求自己产品的技术竞争力。
+
+毕玄：我知道，但是对研发线的人来讲，很难说这是一件好事还是坏事。
+
+好事确实是你做的东西不仅仅这家公司用了，还被全社会更多公司用了，成就感肯定更强。
+
+但在技术层面来讲，商业化之后，很难说大家会觉得我技术上有多大更进一步的空间，因为外部更多是复杂性，而不是纯粹的技术难度问题，是你要支持的业务类型越来越多了。
+
+极客时间：不是说技术要更先进？
+
+毕玄：复杂性也算一种先进，只是大家怎么看待而已。
+
+很多人觉得我支撑更高的并发量，用了更低的成本，这才叫追求了技术，所以很多公司做晋升的时候，业务技术的人会觉得自己没法跟基础技术的人PK，大家都觉得基础技术在解基础问题，复杂度很高，我们后来说还是得区分一下，业务复杂度也是难度。
+
+做业务技术的人，他不是没有技术难度，他的技术难度在业务复杂度，能不能抽象成一个非常简单的东西，去支撑非常复杂的业务。就像阿里，阿里的营销够复杂了吧，每年双十一被吐槽最多的就是营销，但你想，写营销系统代码的人是不是更痛苦？做这套系统的人，他能不能做一个很好的抽象去支撑这么复杂的营销玩法，这也不是一般人做得到的，这也叫技术难度。
+
+技术难度，不能光定义成纯技术侧的东西，其实还有很多是复杂性问题、抽象问题。当然每个技术人爱好不一样，有些会觉得我不喜欢面对这种，他喜欢解决技术问题，而业务是抽象，抽象是很复杂的东西。
+
+
+
+　
+
+水友讨论区
+
+好，到这里今天关于技术演进方向的主题讨论就结束了。其实说实话，在和毕玄聊之前，我非常期待能不能收获一个类似灵丹妙药的方法论，虽然都说没有银弹，但人嘛总是会有幻想，今天聊完，失望多少有一点，但惊喜也意外很大。
+
+失望是因为他说对一个事情走势的判断，最重要的可能是你要去想。这句话非常正确，但是完全没有用。
+
+但意外惊喜是在追问的过程中，他也举例详细分享了自己的思路：所有的技术演进，其实都是围绕着用户对这个产品的核心诉求展开的，通过技术层面的架构改造，来解决用户当下的痛点。这个痛点，是你要挖出来的，你去想现在技术有没有可能把这个痛点往前推进一代，给用户提供新价值，这样才能产生很大的改变。
+
+这个出发点很朴素但也很值得参考，你可以借鉴他的思路，找一个领域的技术演进过程分析一下，看看是否对自己有启发。
+
+欢迎在评论区留言，也欢迎分享你自己的技术方向分析思路。下一讲我们会聊一聊带团队成事的话题，下一讲见。
+
+拓展阅读
+
+1. 毕玄之前就喜欢搞预测，在年末写过几篇预测文（虽然很多后来被打脸），如果感兴趣可以围观：
+
+来一起预测2019、预测下云、AI在2018将会发生什么变化、2017年“工程时代”即将翻篇，迎接”科技时代”、2014年预测行业变化对技术岗位的冲击、回顾2007，展望2008
+
+2. 毕玄非常关注对方向的判断，关于IaaS、PaaS、SaaS和云写了几篇文章：
+
+IT从业者都应关注的软件行业的变化、回顾过去看IaaS的Next、回顾过去看应用PaaS的Next、云计算是新瓶装旧酒吗
+
+3. 关于服务化毕玄之前也写过几篇文章，你可以从中看出他想法的变化：
+
+2015年服务化，你真的需要吗、2017年大部分公司并不需要微服务、2019年Serverless：云时代的软件架构核心思想、服务化的过去、现在和未来、2022年应用架构演进到头了吗？
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/架构：架构师只是个角色，不是个岗位.md

@@ -0,0 +1,289 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            架构：架构师只是个角色，不是个岗位
+                            
+你好，我是叶芊。-
+　-
+今天我们对谈的主题是——架构师。知道你是抱着收获一二三四条方法论的想法来的，没错，今天一定会有，而且非常具体，甚至会具体到你在系统设计文档里的“系统设计思想”这个小章节应该写什么。是不是非常期待？-
+　-
+不过，在讲具体的方法论之前，有几个至关重要的概念我们先要理解清楚，会对你的职业规划有巨大帮助。不然，很多人连架构师具体是干嘛的，能做到什么、不能做到什么都不清楚，就冲着那个概念高喊“我要当架构师！”，岂不是事倍功半，甚至还有可能南辕北辙了。-
+　-
+好，话不多说，我们马上进入对谈。
+
+
+　-
+极客时间：关于架构师，有一些概念大家觉得非常基础，但又好像似懂非懂，想看看你是怎么理解的，比如说到底什么是架构师？
+
+毕玄：其实就是个Title。很多公司不会有明确的架构师岗位，就是做这个事情的时候需要一个架构师，所以你兼任或者指定了一个人而已，不会说这个人他就是个架构师，很少有公司这样，因为这确实会有点问题。
+
+极客时间：那架构师部门是？
+
+毕玄：很少有公司会有架构师部门。就算有都是很小的，虚拟的也可以。是这样，多数不是说这个人的角色就是个架构师，因为这里有个最大的问题就是架构师到底干啥。我们一直都认为架构师他不是个岗位，他只是个角色。
+
+大家的岗位全部是研发工程师，只是说在这个项目或者系统里，我需要有一个人承担架构师的职责，承担这个角色来负责设计整个系统。
+
+极客时间：什么叫设计系统？
+
+毕玄：现在前面有一堆需求，不管是来自业务方还是来自技术方本身，技术方本身就是做基础技术的那群人。
+
+需求有了以后，这个需求要被翻译成一个技术的解决方案，这就是架构师要干的，通常这个人也会承担比较核心的代码编写，其他人会遵照这个设计来完成整体落地，就这个活儿。
+
+极客时间：但是有些好像就负责写方案？
+
+毕玄：有些可能是外部来的，有些是做业务架构的，比如业务方有大需求，这个时候有人要提解决思路，那可能是另外一回事，他可能是不负责落地的，翻译完就随便做做。但这种是很容易虚的，比如你做架构的时候画框说要这么做，最后研发具体怎么做你根本就不知道，可能跟你想的千差万别，因为研发有自己的想法，这很正常。
+
+挺乱的，架构师也搞不清楚到底什么是架构师，反正我们看过很多，最后还是觉得架构师不大适合实体化。
+
+极客时间：在阿里，架构师会分级别吗？比如初级、中级、高级这种？
+
+毕玄：这对我们来讲是负责的系统大小，但这也很主观，可大可小，比如一个小的系统里包括一些模块，更大一点的可能涉及两三个系统，更大涉及上百个，就需要很多的大架构师。
+
+像大架构师会是一个团队，因为会跨很多专业，总架构师一个人不可能全懂，所以他只是根据整个全貌，划定一个指导思想的框架，判断出负责每个系统的架构师在设计的时候要解决好的几个问题，剩下就是你自己的事了，解的思路有时候会给出来，但具体你要跟你自己的想法结合，做好最后的落地工作。
+
+极客时间：总架构师感觉很像导演，像张艺谋导了冬奥会。
+
+毕玄：你可以认为他（张）就是个架构师，他讲思路，下面人支持，至于怎么确保下面执行的过程不要跟他的想法有太大的偏差，他不是靠系统去控制的，他是靠人在打。
+
+但技术上的架构师是我必须要设立一些指标，可以确保你们上线了我也能看，这就是个很好的架构师，因为多数架构师是画完框就不管了，最后谁都不知道程序员自由发挥成啥样了。
+
+
+
+
+
+　
+
+极客时间：现在有很多架构师的课程，教怎么成长为架构师。
+
+毕玄：这课简直太难讲了。外面架构师的课程讲啥的，我都很好奇，以前培训的人问要不要采购，我就说你们不要听他们瞎扯。这个话题我们都想了很久。
+
+极客时间：但大家一般觉得架构师是从初期培养的，比如说最开始先了解架构工具，再讲架构理论等等。
+
+毕玄：这我们从来没有，我之前都是用PPT给大家讲的，因为架构师，我觉得工具一点都不重要。架构师最重要的传达清楚你的想法就可以了，至于你用什么工具一点都不重要。
+
+架构理论，他学完了会发现一点用都没有。像设计原则、设计模式这些东西也不是完全没用，还是有点用，但这就跟数学公式一样，你知道了这些公式，就是学了一个天花板，只是那可能是一个很小的点。
+
+极客时间：那你觉得架构师是可以培养的吗？
+
+毕玄：我以前觉得很难被培养，因为我觉得方法论这个东西没什么用，但后来我觉得方法论还是有点用的，所以我在离开阿里前特意搞了一个架构师培训的班。
+
+极客时间：你讲的是什么？对参加的人有什么要求吗？
+
+毕玄：级别我们其实不区别，班里都是承担过架构师角色的人，大小都有，因为负责系统的大小是知识面的问题。但不管你是哪一级，负责多大系统，我看过我们以前所有系统设计方法都是一样的，大的无非就更复杂一点，可能是分下去有更多人组成。
+
+所以做架构，首先做事的大概思路是可以抽象出来的，比如我的方法第一步是这个，第二步、第三步是什么；另外更重要的是我可以告诉你，我在每一步犯过的错是什么。
+
+因为光讲方法论，最大的问题是讲完之后没有一个人能听懂，他也不会落到自己的实践上，如果你给他讲几个血淋淋的案例，等未来他真正干这个活儿的时候，他也许忘记了方法论，但他想起了那个教训，可能偏差也不大，这就是我们觉得架构师能培养的地方。但其它的，我们觉得确实培养不了，只能实战。
+
+极客时间：讲案例倒很像分享，不太像培训了。
+
+毕玄：因为我们觉得想成为更大的架构师，真的不是靠培训，是知识面问题。
+
+像蚂蚁做的确实好，他们会划几个等级，上面有更大的域架构师。比如说你这个领域是交易，交易里面还有订单、优惠等等，你以前可能只负责优惠这个小系统，只能讲清楚这一块儿，如果你要负责整个，必须要清楚全部的问题。这根本不是培训的活，因为每家公司业务都不一样，而且外面培训很难帮他，只能靠他自己。
+
+极客时间：这是业务架构师，那技术侧的架构呢，也是一样方法吗？
+
+毕玄：对，技术架构师也一样，都是全貌问题，越大的系统，架构师就越难有全貌。因为没有一个人的角色是我来专门看全貌的，只有你干的时候才承受，你被任命了。
+
+他们的区别只是业务架构师的需求来源于业务，技术架构师更纯粹一点，最大的挑战是想好你要解的问题是什么。因为基础技术是需要自己想的，要做什么东西，自己创造需求，业务说实话不需要你想。所以事实上做事的方法都是同一个。
+
+　
+
+
+
+　
+
+极客时间：所以这个抽象出来的方法论是什么，是你之前在公众号上写的架构师套路？
+
+毕玄：对。
+
+
+自己做系统设计的套路：系统设计的目的->系统设计的目标->围绕目标的核心设计->围绕核心设计形成的设计原则->各子系统、模块的详细设计。
+
+
+极客时间：这个做架构的套路，你一般是怎么开展的？
+
+毕玄：首先必须有个最大的架构师，他是划定框的，决定了这次的协作关系。这个架构师，最重要的是定义目的，做一套架构之前他要告诉所有人，这次为什么要做架构级的改造？
+
+因为架构级改造其实不多，这是超级大的动作，所以为什么架构师不大需要，因为老做这么大的，肯定是出了挺严重的问题，像阿里发生过大的架构其实就这四轮，哪有什么那么多架构的事情。正常情况下，在我原来的框里添添改改就行了。
+
+极客时间：方法论有了，我们也用你开培训班的思路，举具体的案例来理解一下其中的每一个环节，第一步是目的，比如说集团上云当时的目的是什么？
+
+毕玄：第一个目的是以后采购的所有机器100%必须是阿里云的，不允许自己采购了，所以我们只看预算，如果大家全部是从阿里云走的，就说明成功了；第二个像PaaS这层我们定义的目的，凡是阿里云有的产品全部不允许自研了，而且要用标准的云产品。
+
+然后下面的架构师会来分解。比如PaaS因为要全部切换成云资源，所有的系统架构师来看他们的系统要搬上去到底会面临什么问题，这些问题提出来会由阿里云负责计算资源的架构师来看应该怎么解决，这就是他们应该干的。
+
+所以越大的架构师，其实越是个框架，是个方向性指导，下面的人都在这个框里。但是因为你定义了一个目的，最后你就可以确保这么多人协作不会走偏。
+
+极客时间：你做统一调度也是类似，第一步提一个大的方向？
+
+毕玄：对，像统一调度涉及基础设施、网络、大数据各种各样的团队，那我就必须说清楚我的总体思路是什么，然后你这部分最重要的是要做好什么，就可以了。你们怎么做起来的跟我没关系，你也不用告诉我，因为我也不懂。
+
+大架构师就是这样的，其实是我给一帮人提了一堆的问题，然后你们去做掉。最难的是提问题，而不是解。
+
+极客时间：为什么方法论的第一步和第二步会有“目的”“目标”的区别？
+
+毕玄：目的是我做这件事情是为了什么，但是目标是我怎么考核你做到，其实是个指标。
+
+因为通常来讲，架构设计最大的问题都是你最后做完了，发现跟当初设计是有偏差的。这很正常，因为程序员会自己发挥，像画建筑设计图一样，你一开始画成这样，最后盖成什么样谁都不知道，搞不好天差地别。所以目的、目标就指标，是做系统架构师在前面要做好的。
+
+极客时间：所以目标这一步，比如说会给一个数字？
+
+毕玄：对，比如说异地多活，核心目的就是把切流要封闭在一个单元里，所以我们一定会考核跨单元的交互，这是会在系统指标里定义清楚的，以后系统上线了，只用看这个就能知道有没有达到我们的设计目标，确保偏差不会太大。
+
+极客时间：会不会有些东西用数据衡量不了？
+
+毕玄：那不会，肯定可以的，如果不能衡量，应该是这个架构师没有想得很清楚。
+
+像我刚讲的目的、目标，其实是应该写在系统设计文档里的“系统设计思想”部分的东西。以前很多系统设计文档里都有设计思想这一小章节，但很多人都瞎写。
+
+极客时间：具体要写什么呢？怎么判断有没有在瞎写？
+
+毕玄：有的人不管做什么系统设计，放进去的设计思想都一模一样，这就是瞎写。设计思想是你针对这一次改造，你觉得所有人需要遵循的最基本的原则是什么。
+
+就像异地多活，我们给的第一设计思想指导就是数据错乱保护，你要确保你的数据不会出现错乱，在下面写各个系统实现的时候，我会告诉你大概的解决思路是什么，在你的系统里一定要把这些写上，其它都是次要的。比如要做分流，我告诉你分流的思路是什么，剩下的就是你正常解决问题而已，随便你发挥。
+
+所以你写的其实就是解决问题的一个大思路，也不用写太细，没有多少人真的会那么细地去看那个文档，你要看你写的这些条，在下面架构师的文档里会不会承接好，会的话说明这真的是设计思想。
+
+极客时间：目的和目标后面就是具体的设计方案了，你们在实际做项目的时候会讨论吗？
+
+毕玄：这个我们没有，我们几乎不做架构理论，最多是在晋升面试的时候留用。
+
+极客时间：不会找其他人看一下我的方案什么的？
+
+毕玄：不会，你想架构师是干啥的？就是前面有个问题，要想一个解决方法而已，这是工程，多数工程师是非常擅长的，尤其是写代码优秀的工程师。
+
+这个能力就跟数学解题一样，只是你解的方法可能有问题而已，但你不会这么认为，技术的人都这样，都觉得我的方法当然没问题。前面大家空对空谈，有可能最终落地真的被你说中了哪些地方确实有问题，然后返工，这很正常，因为他只有到那个阶段才能明白，原来我确实设计的有点问题。
+
+
+
+
+
+　
+
+极客时间：所以整体看架构设计，对架构师来说哪个环节要求最高？前面写设计思想？
+
+毕玄：对，因为很多人根本没有想清楚。大家对系统架构的认知也是这样，前面一页需求，后面一页就是框，觉得架构师这活也挺容易干的，不就是画框嘛。
+
+但最关键的是你的框为什么要画成这样？这就是你的选择，你的观点，说白了前面有个问题，你准备怎么解决，你要把这个解决思路告诉给所有人。
+
+但大家都知道解决思路有很多种，那你为什么选择这种？你的思路是不是最好的？如果不是最好的，你要知道最好是什么。很多架构师是讲不出这个逻辑的。他为什么要把框画成那样，是因为别人把框画成了那样，他只是套用了一下而已。这就不叫做架构设计，这只是复制一下。所以架构师通常是会讲的人，因为架构师是需要传达的。
+
+极客时间：而且前面这一步感觉是不好通过培训来学习的？
+
+毕玄：对，我们只能讲案例，因为选择涉及很多方面，像技术选型需要你“见过猪跑”，还有工程落地问题，你要想到底哪几个地方是一定要解决的，哪些在当前阶段是不重要的，这就是架构师的取舍。你不能说我什么都要做好，那不可能。
+
+像我们做统一调度也是，当时决定做两个调度器，在线的Sigma，离线的Fuxi，然后中间有个所谓的零层来做两层的交互，后来应该是19年合在一起了就是ASI。最早我们也有纠结，要不要做一个统一调度去同时支持在线和离线。
+
+很多人从技术梦想上讲应该先统一，但我坚决不同意，我就跟团队讲这不光是技术问题，还有工程问题。如果统一成一套，光做这套调度器可能就3年了，这3年里我们不会看到任何成果，但我要的是3年内看到类似Borg的混部带来的整体收益，有了收益，以后自然有机会去实现技术梦想，如果没有收益，可能公司隔2年觉得这项目不值得干，直接就不让我们干了，这很正常。
+
+而且关键是这个选择不是我们做到业务效果的障碍，不做统一，也能做到这个效果，统一纯属只是好看一点而已，技术上我也认，我们的方案一看就很丑陋很妥协，但从工程落地上来讲，这就是最高效的方案，因为落地才是最重要的。
+
+极客时间：你觉得落地最重要，但在技术先进度、方案效果和工程落地等等方面上，很多人对优先级的看法可能不太一样？
+
+毕玄：为什么很多技术很好的人在一家公司做不成事情？最大的问题是他不能接受妥协。
+
+他觉得必须我做成这样，才可以。但很多东西都不是这样的，你慢慢其实可以做到那样子，但你要能接受前面恶心一点的过程，反正也是为了最终能做到，要慢慢来，不要太着急。
+
+当时我们做统一调度被很多人狂喷，说你们简直了。他们就觉得你们这伙人是不是觉得太难了想绕路，就被他们鄙视，但这些我都不在乎。
+
+因为我当然也知道有另外一套更好看的，但关键是要判断工程节奏，以及判断如果用这种丑陋的方案是不是做不到业务效果，如果做不到，当然就是另外一个事，关键它不是阻碍的点，对不对？那干嘛挑战难度。反正我觉得挺好的，能做成就行了，你管我什么方案，而且这个方案我会逐步变完美的。
+
+　
+
+
+
+　
+
+极客时间：总结一下，你觉得一名优秀的架构师应该具备哪些能力？
+
+毕玄：对架构师来讲，第一要非常清楚知道你做的这个事情的意义，这个还是核心问题，在这个意义上你再去做技术方案，思考技术上怎么去解决掉这个问题，那你肯定会有很多种方案，这就是权衡要考虑很多方面。
+
+像早期的HSF、T4我们技术选型都出了很大的问题，这其实是架构师最重要的责任，如果你的解决方法有问题，那后面就彻底完蛋了。如果你做比较顶级的方案，还有之前讲的天花板问题。
+
+另外就是你对未来发展趋势的看法，比如说HSF我们认为就是为Java场景设计的，但没有想到一家公司一定会发展成多元化，一开始没留口子，后面根本没有机会，所以后来多元进来就不知道怎么搞了，这是设计问题。
+
+有时候架构师还会面临团队分工问题，比如说你需要的技术，有三个团队提供，你选谁？这也是架构师要解决的，我们会看平时哪些人做整个系统更有想法，而不是只是我那部分代码怎么写，也会从团队定位和长远发展看，做这个东西对哪个团队来讲是他的长期主业。但这是非常复杂的话题，你要有自己的观点，肯定会得罪一些人，这很正常。
+
+所以架构师是有很大的挑战的，有些时候要面临一些比较复杂的问题和方案。
+
+极客时间：但这几点也都很难培养，只能以战养兵。
+
+毕玄：纯培养我觉得太难了，只能尽量告诉他们在做每一步的时候应该考虑好什么，比如技术选型，我们会大概告诉你技术选型的思路是什么，要注意哪些点。另外也会重点强调你做一个架构设计，千万别随便写设计思想。
+
+极客时间：对于职业成长路径来说，现在大家好像普遍觉得不想做架构师的程序员不是个好程序员。
+
+毕玄：因为看起来好像就是架构师负责了整个系统。
+
+极客时间：那程序员的最终归宿是架构师是真的吗？
+
+毕玄：不会，这成长路径有问题。程序员成长路径的一条就是继续做程序员，这还是得一直做下去的，另外确实有些程序员成长为了架构师，但其实他就是一个兼职，研发工程师兼架构师角色。
+
+如果谁说我就只设计系统，这人很多时候没活干的，因为系统不需要老设计。万一你真的设了这个岗位，那完蛋了，因为这个人就会老想，会凭空创造出来一些需求，这就尴尬了。
+
+因为架构师是设计系统结构的人，不是设计细节的人，细节才需要经常变的，所以之前专职架构师部门最后会变成一个很虚的部门，因为你又不实干，你讲了很多，但别人研发觉得你又不懂，他还是自己干一套，跟你的设计方案一毛钱关系都没有。
+
+
+
+
+
+　
+
+极客时间：对于想走架构师这条职业路径的同学，一般架构师是怎么选出来的？
+
+毕玄：一般就是研发里写代码写得比较好就去做，一个项目比如说业务方有需求了，那你就牵头去处理这个需求去做规划，所以平时根本不存在这个人，只有这个项目出现的时候才会突然说任命了谁去负责横向的架构。这当然是基于大家日常对他的认可。
+
+极客时间：所以即使以架构师为目标，大家也还是要从程序员正常往上走？
+
+毕玄：对，不会因为你是架构师就给你定什么级，当然架构师肯定会比程序员更有优势，这个我们也认。
+
+因为做过架构师的人说明你可以承担更大的责任，除非是做专业技术的像虚拟化、内核，对业务团队来讲，为什么那么多做业务研发的程序员想做架构师？说白了他只是想负起一个更大责任而已。
+
+多数公司的发展路径是有些程序员他能兼任架构师，他可能就变成Leader了，可以负责这个系统了。因为架构师其实已经具备技术层面、业务层面的技能了，只是欠缺的是管理、行政什么的，他离Leader只剩一步。所以架构师，确实几乎就是Leader的前提。
+
+极客时间：但好多人只想当架构师，不想当Leader。
+
+毕玄：我觉得很多人想成为架构师的目标是想做Leader，而不是想做架构师。当然有些人也喜欢做架构师，就是我不想承担管理责任，但是我又想负责整个系统，这种人也有，这也没错。
+
+但通常来讲，作为一个技术Leader，最重要的当然是技术能力，管理能力是可以培养的，所以我们不会接受说这个团队有一个管理能力很强的人，因为他技术能力差一点所以要给他配个架构师，这简直太丢人了。所以通常就是架构师做了Leader。
+
+　
+
+水友讨论区
+
+说实话，今天聊完我对架构师有了全新的认知，之前我一直以为架构师是一个岗位，就是有个人一路打怪升级上去最终成为了一名架构师。
+
+毕玄认为，架构师就是个角色，有一堆架构演进的需求来了，需要被翻译成一个技术的解决方案，有个人出来干这活，根据系统全貌划定一个指导思想的框，也承担了比较核心的代码编写，来保障最终的项目效果，这个人就是架构师。
+
+如果你还想成为一名优秀的架构师，毕玄认为应该具备几大核心能力，核心是要想清楚并且讲清楚你做这次架构改造的意义，包括目的和目标，在意义上再做技术方案的思考和权衡，包括技术选型，顶级方案的天花板问题、对未来发展趋势的看法、团队分工问题等等。
+
+你对架构师的理解是什么呢？你眼中的架构师能力模型是什么样的，对这些能力有怎样的排序呢？如果你有自己的架构方法论，也欢迎分享，期待在留言区见到你的思考。
+
+　
+
+到这里，5场专题研讨会就结束了，我们从“个人成事、方向选择、团队带领、做事文化、架构修炼”这5大方面，把毕玄分析问题的思路和做事情的方法浓缩给你，不知道你收获如何。
+
+当然想要把方法论化为己用，你还需要丰富的案例，所以，我们接下来将坐上时光机展开一段探索之旅，看看毕玄在二十多年的技术人生中，做过怎样的选择，又经历过怎样的波折，才总结出这5大方法论。期待和你再会，下一讲见。
+
+拓展阅读
+
+毕玄在自己的公众号上写了一个架构师系列，详细讲了方法论中的每个步骤，你可以参考：
+
+0. 聊聊系统设计的套路-
+1. 系统设计之系统建设的目的-
+2. 系统设计之系统建设的目标-
+3. 系统设计之达成目标的核心问题-
+4. 系统设计之解决核心问题的设计-
+5. 系统设计之设计原则
+
+另外还有几篇针对自己经历的架构反思：
+
+我在系统设计上犯过的14个错-
+多个团队的技术方案冲突，怎么决策-
+架构师画像
+
+                        
+                        
+                            

专栏/超级访谈：对话毕玄/番外：一位险些没上得了大学的青年，如何开启计算机征程.md

@@ -0,0 +1,260 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            番外：一位险些没上得了大学的青年，如何开启计算机征程
+                            
+你好，我是叶芊。-
+　-
+今天这篇又名“大佬养成番外之——大学篇”。-
+　-
+毕玄的经历，相信你已经非常熟悉了，外界写他最吸引眼球的宣传语一般都会提到他是生物系毕业的，比如“从生物系学生，到阿里传奇P10：毕玄是如何完成自我蜕变的？”-
+　-
+虽然八卦，但不得不说，他相当丰富的大学生经历，是毕业后能顺利转岗成为一名程序员的必备要素，毕竟大佬也是需要从零开始养成的。-
+　-
+那让我们一起把时间线拨回1998年，看看这位险些没上得了大学的青年，是怎么居然因为太无聊和电脑结缘的？
+
+
+一条重要说明👉：今天的对话是基于毕玄大学经历的一场漫谈，主题是“选择”，希望了解毕玄接触计算机的初心，把他的早期想法展现出来，与他后期观点形成对比，看看是否能找到他在面临无数人生选择时的底层逻辑。
+
+如果你对他起步阶段的具体技术学习过程感兴趣，可以结合文末链接一起看。
+
+　-
+极客时间：一直会有人好奇程序员非科班出身和科班出身的不同，你是非科班，为什么当时学生物后来转了程序员？大学那会为什么会想学生物，自己主动报进去的？
+
+毕玄：好吧，这是一个悲哀的故事。
+
+极客时间：啊怎么讲？
+
+毕玄：因为我高中报大学的时候比较失误，我们以前考大学，你们不知道，跟现在差别是非常大的，当时是后出分先报志愿。
+
+现在是先出分。关键现在是出分然后可以报很多志愿，当时我们是只能报很少的志愿，可能是3个志愿6所学校这样的，而且先录批只能报军校，第二个批才是正常。当时，我因为家里以前一帮人工作的原因，那个时候特别想读的是邮电大学。
+
+
+1998年的理科考试，理科考语文、数学、英语、物理和化学。报考顺序是5、6月份先报志愿，一个月左右后高考，然后出成绩，最后等录取通知书。
+
+
+极客时间：邮电大学？当时你的选择可以具体聊下吗？
+
+毕玄：我是1998年高考，我们那个年代最火的学校是邮电大学。邮电大学里面中国最牛的两所，一所北邮一所南邮，北京邮电大学，南京邮电大学。我们很多人都很想读邮电大学，我是因为我家有很多人在邮电这个体系内，所以我的志愿报的很差，第一志愿北邮，第二志愿南邮，没了。
+
+因为那个时候邮电大学特别火，我住江西的，江西那年南邮的录取分数线接近清华，北邮应该是超过了清华。所以其实是我报的两个志愿都没有被录取，我都以为我要重新读高中了（笑）。
+
+但是后来被我们省的大学南昌大学捞回去了，好像以前是可以这样的，就你可以没报它，但本省的大学应该可以从现在这批没有被录取的人里面捞，它想要哪些人。然后我就被捞进去了。
+
+极客时间：没被理想的大学录取上，你有想过重读吗？
+
+毕玄：想了，我当时想了很久要不要重读，后来我觉得还是算了，重读还是太累了。
+
+不重读，然后被南昌大学捞进去了以后，相对来讲我的分报南昌大学是比较好的，所以我可以选要读什么系。在我们那个年代最火的一句词是：21世纪是生物的世纪，所以我就觉得那就报生物系吧。
+
+我们这些人回头看也觉得，最大的问题是我们那一代人，不过我觉得现在也一样，多数人其实读大学前你根本不知道自己要读什么，这是中国学生可能比较普遍的，国外我觉得好很多，因为他们多数是不先选专业的，就你进去先通识教育，加上选课又很自由，后面读了两年以后再选，我觉得是有可能会知道我想读什么的。
+
+但是中国不行，我们那个时候更不行，生物系，我都不知道生物系是干啥的，也根本不知道生物系出去以后要干啥，你只是听到很多人说21世纪是生物的世纪，现在也还是这句话，22世纪是生物的世纪，应该还能听到这句话（笑）。所以像我知道的很多人也都学的生物，阿里之前有好几个人都是生物背景的，多隆也是生物系的，还有福贝，我们三个人都是学生物的。
+
+极客时间：你们都是被世纪口号忽悠进去的？
+
+毕玄：也不知道，反正都是命运让我们选择了生物系，所以我就读了生物。
+
+　
+
+
+
+　
+
+极客时间：那大学进去之后是生物系，你是怎么跟电脑结缘的？这个差别还挺大的。
+
+毕玄：去学校读了生物以后，我很快可能就觉得生物不是我想读的，但电脑也很凑巧，反正有很多凑巧的因素。
+
+最早是因为我到大学以后要军训，军训的时候很无聊，我们当时不是去军队军训，就是在学校，军训完了晚上的时候没有什么事可以干，我和另外一同学俩人就在学校里瞎逛。
+
+逛的时候我们觉得太无聊了，真的太无聊了，因为1998年上网还没有，应该很少有学校能上网但非常慢，而且学生也不知道上网干啥，1999年才比较多，因为腾讯、阿里全都是1999年创办的。所以1998年的时候其实什么都没有，没有娱乐生活。
+
+我们俩在学校逛的时候看到有个机房，最早机房好像可以上机玩Windows或者DOS，当时我们俩觉得反正也没什么事干，就进去了，结果进去之后，关键是我们发现也不知道玩啥（笑）。因为我俩以前在高中是没有怎么学过电脑的，什么都不懂。我们去了机房，也不知道玩什么，我就看旁边的人，发现旁边的人都在干啥呢，都在打字，练盲打。
+
+极客时间：盲打？大家不是上机做实验或者玩游戏什么的？
+
+毕玄：那个时候不像现在，那会多数人刚到大学的时候，电脑相关的背景知识都是几乎没有的，其实都是从盲打开始，大家可能也很无聊（笑）。所以一进来，你发现整个机房的人哇居然全部在练盲打，简直了，也挺卷的，搁现在肯定在玩游戏了。
+
+然后在那个环境里你就不由自主地被卷进去，因为你发现旁边人打字好快，就觉得我也要打得更快。所以军训一个月的结果就是我竟然练会了盲打，对电脑开始有一些兴趣了，觉得也挺好的。
+
+极客时间：所以你是起步的时候有成就感了。
+
+毕玄：然后大学就开始了，因为军训结束以后我们宿舍就讨论要不要买个电脑，就一起买，那个时候我们都是这样的，每个宿舍的人都觉得太无聊了，得买台电脑，当然了买电脑还是得玩游戏的，大家的第一诉求肯定是玩游戏。
+
+反正就开始买了，但买电脑的这个过程，确实让我对这个行业可能更有兴趣了，因为我们那个时候买电脑跟现在是完全不一样的。
+
+　
+
+
+
+　
+
+极客时间：那个时候买电脑，是组机吗？
+
+毕玄：对，以前买电脑，尤其学校学生，更倾向的是我买一堆的零件，自己组装，现在都是我买一台整机就用着好了，但以前不是。
+
+我们去电脑市场买一堆的零件，开始学怎么组装起来。因为我们是生物系的宿舍，计算机系不在这个校区，他们在另外一个校区隔很远，所以我们跟计算机系的人其实不熟。但我们系有几个人，就很喜欢折腾电脑，也不知道来干啥，就觉得很好玩，所以后来这些人就开始负责各个宿舍电脑的组装。我们就开始瞎弄。但好处因为大家都不懂，你有瞎弄的空间。
+
+那个时候大家希望是我用很少的钱，买到一台还不错的电脑，尽可能把这个电脑的能力发挥得比外面组装的更好，所以我们会学很多硬件层面的，比如说像什么CPU、调频啊各种各样，但这些都是自学，我们确实没有任何机会，因为选修，你也选修不到计算机系的课，就很尴尬。反正就自己玩。
+
+极客时间：那个时候你学硬件是怎么学的？看书吗？
+
+毕玄：也不知道，我们好像没怎么看书，反正就瞎弄，可能有几个人会告诉你像CPU跳频主要是跳线问题什么的。我觉得最重要的是我们不怕。
+
+跟很多人聊，现在学电脑硬件的很多人可能是不敢，比如给你一堆零件你敢不敢随便弄，你可能怕烧掉了。在那个时候对学生来讲，如果烧掉了也是很多钱的，可能几千块钱没了，哇那宿舍的人得把你砍死（笑）。但是我们好像也不怕，也不知道为什么，反正就瞎弄。
+
+组装电脑的这段时间就会接触电脑行业的很多人，当然是偏硬件的人，因为我们那个时候经常去南昌的电脑城跟那些装电脑的人聊，后来他们说不然暑假你们来装电脑吧。那个时候装电脑挺赚钱的，因为信息很不对称的，就是看你懂不懂，你不懂我随便给你开个价，不像现在可以网上查一下，几乎不会有太大偏差。但以前偏差非常大。
+
+极客时间：所以看你对电脑逐渐感兴趣的整个经历，大家如果兴趣不同，选择差异还挺大的，当时是你们在宿舍里面一起组机，还帮人家好多宿舍都组好，那其他人是就去玩游戏了吗？
+
+毕玄：对，那肯定呀，因为主要目的就是玩游戏，后来就变成了上网。
+
+极客时间：你当时有玩游戏吗？
+
+毕玄：也玩，肯定也玩，但我可能没有那么感兴趣，我对游戏好像天生就没有那么强的兴趣，所以也就觉得没什么意思。
+
+极客时间：这个差异性可能是大家刚开始就不一致的吗？
+
+毕玄：就目的不一样。对我来讲，电脑可能最主要的不是玩游戏，但对于别人可能我买电脑的目的就是玩游戏。
+
+我后来也不大玩硬件了，因为组装门槛其实没有大家想象得那么高，硬件要么就是组装，要么就是设计，因为你不可能自己做硬件，这个可能性是不存在的，所以就剩组装。那会我们觉得去电脑城卖电脑，也就帮人装装电脑，好像也不是我们想干的，就不是很有意思，因为那个时候你也不会想着要赚钱，没有这个诉求。
+
+　
+
+
+
+　
+
+极客时间：你大一接触电脑之后感觉有点意思，那大二呢？后来也不玩硬件了，你找了什么新活动？
+
+毕玄：大一可能是个开始阶段，我大二学少量的专业课，植物、动物、基因等等，这就很偏生物的，我上了几堂之后，实在不想上了，我觉得这个很不适合我。但那个时候我对计算机就越来越有兴趣了。
+
+到了大二就是1999年、2000年，开始流行做网页，做网站了，因为腾讯阿里也创办了，外面有很多人很多公司就想做一些网站放在公网上，然后我们觉得做网站也挺有意思的，你可以在互联网上放个东西，可以自己随便搞。但那个时候其实是个静态，就不像现在是动态的网站，静态是每页都是写死的，里面是什么内容就是什么内容。
+
+极客时间：写死的，类似展示页吗？
+
+毕玄：对，就是个展示，可以认为就是把文本放到了网上。那个时候大家开始学怎么做网页，就只能自学了。所以我以前还会说，自己挺擅长用PhotoShop之类东西的，因为以前做网站的三个东西三剑客，PhotoShop、Dreamweaver，还有个什么来着（Flash），反正就三个组合开始做的网页。
+
+做网站，开始是觉得挺有意思，我学了一段时间之后，有家公司去我们学校想找人帮他们做一个网站。也不知道为什么我就去了（笑），虽然我是生物系的，计算机系的人去的好像还不多那个时候，当时我就去了。
+
+去了之后，我就相当于变成在公司了，在一家江西那个时候的门户网站开始做一些网站静态的东西，我感觉还挺有意思的，哇还能赚钱，就觉得这个活简直太好了，所以越来越进坑了。
+
+那个时候做网站是特别特别赚钱的，因为是按页收钱的，不是现在我给你做个网站多少钱，以前是我给你做一个网站，这个网站总共有几页，比如说有3页，你打开能点开的总共就3页哦，这样的网站大概要800块，在2000年800块对一个学生来讲还是很爽。后来我跟那家公司有些销售特别熟，他们会私下给我一些单子说我手上有个单子你去做吧，给你多少钱，就不走那家公司。
+
+极客时间：跟销售的关系特别熟，这个在程序员中还挺少见的，你是平时会跟人家聊吗还是怎么？
+
+毕玄：那没有，其实这个是互利。销售他寻求利益最大化，对他来讲，找公司的其他同事肯定会要他更多的钱，这很正常，但学生嘛，也无所谓，给多少钱就多少，因为我完全不在乎多少钱。
+
+加上我又不准备靠这个来赚钱，我只是需要做点东西就好了，如果顺带还能赚点钱对学生来讲那就更好。而且对学生来讲，钱其实也不少，干几天就能赚几百块简直太好了，因为我后来大三的时候正式上班一个月就2000。
+
+极客时间：所以你就冲着做东西去，顺便赚点钱，但是后来很快网页就不赚钱了？
+
+毕玄：那个时候我做了一些小网站，你的技能就会越来越熟练，但这个技能很快就升级了，这种好日子大概持续了一年，一年之后就不再是这种报价体系了，就变成你的网站是要带动态的。
+
+极客时间：所以是做了一年，技术就迅速升级了。
+
+毕玄：对，我们回顾会发现很多技术是会非常快被平民化的，阿里后来的很多技术也都是这样，开始的时候它显得特别高端，其实是因为大家都不懂。
+
+但很快，尤其中国，懂的人就会多，因为说白了是大家都会发现一个行业这么赚钱，就会涌入一大批人，如果学习的门槛又没有那么高，很快人才就饱和了、溢出了，所以大家就开始卷。以前说做3页是800块，后面可能变成了不管你多少页总共800块，那就不一样了，迅速市场价格就下去了。
+
+当然也不是坏事，因为平民化了所有公司就开始做，以前太贵了不是所有人做的起，但对很多有技能的人来讲，我当时就是，会觉得哇这个太难了，太卷了。
+
+极客时间：技术升级之后，你去学做动态页了？
+
+毕玄：恩后来我们就发现这个时候有另外一个门槛更高的东西是更赚钱的，那个东西就是做动态页，不再是原来的静态页。
+
+因为静态页其实是很简单的，大家通常的做法是先用PhotoShop做一个完整网站的图片，做完以后开始切割，切割完写HTML就构成了整个网站，所以熟练的人一天就可以做完，速度非常快。但后来这个门槛上去了，大家开始学动态了，动态就写要程序。
+
+所以我开始学习写代码，就彻底走向了“码农”方向了。以前只是个PhotoShop艺人，甚至只是去抄一下而已，因为那个时候很多人的做法是去抄韩国的网站，因为韩国做的特别好，他们网站设计都非常精良，中国的都很土，所以很多人就去韩国网站打开截图，把里面的字全换掉，搞定，那个时候也不存在版权。
+
+极客时间：这会你是怎么学的？
+
+毕玄：到动态这个阶段开始学习一些代码，我只能自学了。那个时候用的还是ASP，现在应该是ASP.NET就Windows的，我们最早其实全部是微软体系，因为微软做的东西特别容易上手。然后我们开始学ASP，学习一些新闻发布的网站、留言板啊这种比较常见的动态程序开发，其实这个也还好。
+
+但你能看到，这个门槛确实比前面是高很多了，就是前面学的人是非常多的，很容易进来，但到了这一步你会发现从静态变成写程序的人，确实是少了，就这一关就少了很多人，刷掉了很多人。
+
+　
+
+
+
+　
+
+极客时间：从那之后，你开始搞动态网站写代码了，有一点好奇，你的学校和外面是怎么平衡的？
+
+毕玄：学会了以后，我应该是大三的暑假就正式开始写程序了，因为那个时候我已经觉得未来我肯定不会做生物了，真的没有兴趣，而且一开始的时候我混的就是外面的计算机圈，跟南昌做计算机网站的一帮人比较熟，他们都是工作的人。后来因为我在外面做了一些东西反向和学校计算机系的人认识了不少，我们当时有个工作室，就在南昌大学，是负责给南昌大学做网站的，所以第一版南大的网站是我们做的，里面就我一个生物系的人，其他全部是计算机系的。
+
+所以我就变成了准计算机系的人了，但我也没有上过计算机的课，主要是我觉得大学上课也没什么意思，外面更实战，外面是有一家公司，我给了你个需求，你在多少天就必须做出来，这个可能逼着你反向更快地学习，因为这是必须的，你做不出来，后果不堪设想。
+
+大三暑假，我就开始正式去一家专门做这种网站的公司，那个时候应该算上班了，都不是实习，我跟上班的人一样非常正式地干了几个月，那个公司的程序员特别少就三四个，后来干着干着就变成我是主力了，可能学生的学习动力更强一些。后来我就做他们那家公司相对大一点的网站项目，断断续续都在那家公司做，包括开学了以后我都在那做，所以生物我可能就学的很糟糕。
+
+极客时间：那个时候上班是？
+
+毕玄：正式工资，不是实习工资。
+
+极客时间：那学校的课程呢，不太去了吗？
+
+毕玄：几乎就不上了，所以在期末考试的时候，我老师还问你是我们系的？我说我是你们系的（笑）。
+
+极客时间：考试是怎么解决的呢？
+
+毕玄：考前还是要稍微突击一下的，那个时候我们系专业课其实老师对我们很好，一般来讲不是很过分的专业课，老师在期末考试的时候都会出去，然后剩下就可以自由发挥了，所以一般我的专业课是可以踩线过关的，看我大学的成绩，专业课基本是在60-70之间，就是这样，没有更高了，没有一门会超过这个分数线，算是混过去了。
+
+所以到了大三我已经算一个很职业的程序员了，应该算，因为我其实是正式公司的正式员工，跟别人没有太大区别。到大四是因为就不能了，要写论文，我就没在公司上班。另外也是因为到了大四我也不想在江西继续工作了，如果想的话也能继续呆，但我想离开，觉得还是应该去大城市。
+
+　
+
+
+
+　
+
+极客时间：关于人生选择，在毕业之后，你是转成程序员了，那你同生物专业的同学们，有跟你一样换专业的吗？
+
+毕玄：我们班应该只有2、3个后来是不做生物的，有一个应该也是对计算机感兴趣，他是研究生直接就读计算机系了，可能因为我已经在公司工作，所以我觉得这玩意没有必要读研究生，我觉得还是社会可能更能让你学到东西。
+
+因为我以前去计算机系了解过一点，跟计算机系的一些人聊了一下，我觉得他们好像也没学什么东西，而且他们很多人学了很多年，反而是不大想做计算机这个工作的，因为读的很枯燥，就不想学，但不在这个系的人，像我们可能就有很强的兴趣，然后会很主动。
+
+极客时间：所以学习新领域，在一开始的阶段怎么激发自己的兴趣，可能很重要？
+
+毕玄：我大学做计算机只是觉得好玩，就这个原因，也没有什么，然后觉得自己学起来也很轻松。因为学生物我觉得太难了，学的很累，就算专业课认真听，我也就只能考到那个分，那我觉得我太难了，但计算机我随便搞搞，好像比多数人会好那么一点，当然这个兴趣就上来了，成就感就在。
+
+我现在觉得为什么海外很多教学会好很多，因为他们大学是非常知名的教授来上本科生的课程，这个是不一样的，他会让你看到学这玩意到底有啥用。因为我们多数是不知道的，就是说你让我学物理，如果我不知道学物理有什么用，能够解决什么问题，那我就觉得这学来干啥，不就是考分，而且还那么难考，我才不考嘞，但是如果你发现哇学这个东西，原来能解决现在人类面临的问题。
+
+极客时间：就有种使命感。
+
+毕玄：所以我跟我家小孩说你就应该学生物。
+
+因为他本来对动物、昆虫非常感兴趣，喜欢养各种昆虫，再加上我会跟他说生物里面对人类史有影响的很多问题，像看《人体简史》、脑神经科学家的采访什么的，听他们讲你就会知道哦原来研究这些的意义是对人到底能解决什么问题，你就会觉得，哇如果我真的能够研究出这种问题，那在人类历史上，跟计算机系的人根本不是一个档次的。
+
+可能很多人都没有讲清楚这个问题，就是我学这个到底是干啥，有什么用。总得有点用吧，你不能说我学了个东西就为了考个60分，还是90分，这个意义很小，没有多少人是这个动力的。
+
+极客时间：当年你那些同学，后来没有转行业的继续走生物路，你觉得他们有找到学生物的意义吗？现在大家的近况如何？
+
+毕玄：有些有，有些可能也没有。其实大部分人读这个专业不知道我出来能干什么，我们系的很多人毕业了问自己到底能干啥，没有人知道。
+
+但我们那一届比较幸运，我们2002年毕业的，当时生物刚被列入了高考科目，那高中就有师资需要了。但生物系在江西是非常少的，那个时候江西师范大学还没有生物系，只有我们是正统的，尽管大家可能学的也很烂，但毕竟大学专业是生物工程，所以很多高中都是立刻来我们学校要生物工程的人，只要愿意，你就可以去，大学是多少分都不重要。
+
+然后你竟然就此就进了江西的名校，现在我同学大部分都在江西非常重点的高中做生物系的教导主任，因为他们是第一届，这就是命运。第二届就不是这样了，因为江西师大就有了，那别人肯定是倾向师范大学的人，毕竟专业老师，我们这都是外行。
+
+但我们有少数几个同学继续读到博士了，因为生物要非常好的话差不多都要到博士，然后开始领导实验室做一些研究，我们同学有的在北大带一个实验室。但做研究的比较多，大部分是做医药的，或者更危险的就是武器、军工。
+
+　
+
+水友讨论区
+
+今天我们就轻轻松松地随便聊点。现在你有在学什么东西吗，目的是什么呢？在学习过程中有挖掘到自己感兴趣的点吗？如果你是一名开发者，你和计算机的缘分是从什么时候开始的，当时有想用计算机做点什么吗？
+
+欢迎积极讨论参与盖楼，我们留言区见。
+
+到这里我们和毕玄的所有对谈就结束了，非常感谢你的支持，希望这场毕玄的20年技术人生复盘对你有帮助。
+
+最后为了能更好地了解你对专栏的看法，我也特别准备了一份问卷，欢迎你提出建议或意见，期待听到你的声音。
+
+拓展阅读
+
+从业余程序员到职业程序员，如果你对毕玄在起步阶段的技术学习过程感兴趣，可以看这篇他的复盘：程序员的成长路线Remix
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/00篇首语认识汤峥嵘.md

@@ -0,0 +1,52 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            00 篇首语 认识汤峥嵘
+                            你好，欢迎来到《超级访谈：对话汤峥嵘》这个专栏，我是专栏编辑王利莹。
+
+汤峥嵘是谁？现为智能穿戴与健康大数据公司云柚智能的创始人兼CEO，1995年他在美国硕士毕业后，开始了美国10年的职业生涯，前6年在匹兹堡工作，后4年辗转硅谷。2004年回国加入阿里巴巴，前后在淘宝、支付宝、B2B任职，后历任微医（挂号网）CTO、途牛CTO、在线教育公司iTutorGroup (VIPABC) COO兼CTO。
+
+回顾他留学至今的经历，相信你能看到一个普通程序员到CTO的成长跋涉。在美国十四年求学工作，他经历过职业快速成长期，也曾有迷茫。留学生活是汤峥嵘蜕变的开始，逼迫他无论大小事必须自己做选择；第一份工作让他明白做技术，技术能力是第一位的，只要有能力，公司倒了都不怕。而在机会众多的硅谷，他也曾看不清未来，遭遇职业发展瓶颈。回国后加入阿里，对他这个在美国工作10年的人来说，绝对是对价值观的一次洗礼，阿里8年，无论从做人做事方法上，还是在管理理念上，都改变了他，让他一度认为阿里文化无敌。之后经历的几家公司，其中途牛对他来说又是新的一次跃进，更深度参与业务，和公司一起野蛮生长，也让他真正明白了创业该怎么做。
+
+时间回到 2021 年末，上海的疫情还有零星分布，我们与汤峥嵘初步商定了这个专栏的计划，并去上海进行了采访。采访回来，飞机落地北京后，上海某区出现阳性病例，距离我们的采访地点大概 10 公里，不在同一区，算是有惊无险。疫情时期，人与人之间的交流好像变得更艰难了。但我们总算拿到了采访的第一手资料。
+
+这个专栏会围绕汤峥嵘的经历与思考，以访谈形式展现。我们将从他美国十四年的学习工作经历聊到回国后的发展，关注他回国后一些认知的改变。回顾一个普通程序员成长为 CTO、CEO 的历程，看看哪些重要节点在发挥作用？是运气使然，还是努力的结果？以及关注他在经历了二十多年职场工作后，现阶段对管理的理解。同时，你也会看到发生在他身上的有趣的故事。
+
+其中让我印象比较深刻的是他在美国求学时期，曾经在纽约一家小超市打过一个暑期的工，看起来这段经历只是人生中的小碎片，没想到 22 年以后，途牛在纽约上市，汤峥嵘作为 CTO 去纳斯达克敲钟，机缘巧合下他又回到这个曾经打过工的地方，见到曾经一起工作的主管，一个巴基斯坦人，一切好像没怎么变，还是做着和 22 年前一样的工作。
+
+这听起来是很戏剧性的经历，22 年前纽约市的一个最底层的打工仔，今天能够成为上市公司一员。对这段经历他还发过朋友圈，有人说这个故事很励志。但他经历过后，更多的是思考成功和幸福的意义。这件事让他意识到，靠自己的勤奋，在异国他乡找到一个属于自己的家，也是一种成功，或许更加值得炫耀。
+
+在这个专栏中相信你还能看到更多有温度的故事，有态度的观点。如果你在成长过程中遇到过未获解答的疑问，比如：
+
+
+职业成长中要实现上一个台阶，要经过哪些努力？
+当遇到职业瓶颈的时候，该怎么做选择，改变现状？
+怎么才能得到贵人相助？如果真的没有遇到怎么办？
+假如遇到岗位频繁变动的情况，个人如何“拥抱变化”？
+如何选择值得奋斗的行业方向？
+……
+
+
+从汤峥嵘的个人经历和思考中，我们或许能找到一些答案。
+
+经过 100 多个问题的碰撞，我们将这个专栏分为认知升级、职业成长、管理经验三大模块。在职业成长、管理经验模块，主要从他的成长经历、职业发展、管理提升过程中寻找可借鉴的选择、观点和方法。在认知升级模块，会主要跟你分享，性格对人的影响是很底层的，了解自己性格的重要性，性格也被当作他认知自己的底层数据。
+
+汤峥嵘喜欢给自己团队的伙伴做性格分析，用的是国际流行的职业人格评估工具——MBTI职业性格测试，这套理论模型从复杂的个性特征中，按动力、信息收集、决策方式、生活方式4个维度，把人分成16种性格。他发现程序员大部分都是ISTJ型（内向、实感型、理性的，喜欢按规划、规则做事）的性格，他也是这个类型。如果把汤峥嵘作为一个ISTJ型的案例，那么他的思考方式，解决问题的方式你或许可以借鉴。
+
+通过这个专栏，希望你能获得什么呢？
+
+第一，希望你通过看别人的经历，拓宽视野，了解原来没有了解过的领域。期待你通过某一段故事，某一个观点，对照自己面临的问题或困境，找到做下一步选择的更优解。更重要的是增加看待这个世界的新视角。
+
+第二，关于成长、职业发展、管理等话题，虽然也老生常谈，但如果你能有“原来他有不同理解”或“我以前怎么没考虑到这个层面”的感悟，当然更好，这将是对这个专栏的重要肯定。
+
+正如汤峥嵘说的，“每个人都会有自己的经历、自己的经验，别人的经验可能对你来说永远无法复制，只能借鉴。无论结果成功还是失败，当我们越了解自己，越能接纳自己的过去，就越能包容外面的世界，因为很多时候感觉很多人活得很挣扎，都是自己内心的问题。”
+
+“搞技术的人，大部分都是理性的人，也很难相信别人告诉他的理论。包括这个采访，其实只是一个案例，只在这个案例中找到适合自己听的东西就好，也不要忽略全世界其他的案例。但是这个世界的数据太复杂了，我们没法收集所有数据，我们能做的就是慢慢了解自己，看看自己的数据到底是什么样，根据数据改变自己，就是我现在的做人哲学。”
+
+接下来每一篇内容我们都会以访谈形式展现，欢迎你多发表看法，如果你觉得内容不错，也欢迎把它分享给你的朋友。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/01看似理性的程序员为什么可能是最不讲理的？.md

@@ -0,0 +1,173 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            01 看似理性的程序员为什么可能是最不讲理的？
+                            编者按：这次采访，汤峥嵘提到最多的是他做人做事的方法，总结为 8 个字“了解自己，理解他人”。这几个字乍听起来似乎是鸡汤，你可能会想：我也知道应该按这 8 个字进行人生的修行，但具体怎么才算了解自己，又怎么才能理解他人呢？
+
+针对这个问题，汤峥嵘做了 360 度的解答，从他的思考总结、他的经历，你也能看到他在践行这套自己信任的方法论。
+
+在我们的对话中，会频繁提到 MBTI 性格测试——一套非常流行的职业人格评估工具，它把人的性格分成 16 种，汤峥嵘是其中的 ISTJ 型人格（内向、实感、思考、判断），而他也发现大部分程序员也都是 ISTJ 性格的人，如果你也想了解自己的性格，可以自己先测试一下。
+
+理科男看似是最讲理的，但为什么越理性的人在面对冲突的时候，越容易做出不合逻辑的选择呢？这和性格有关。如果把汤峥嵘作为一个案例解析，他是 ISTJ 型人格，大部分程序员也是这个性格，那么他的思考方式，解决问题的方式你或许可以借鉴。
+
+接下来的两节，我们会从 MBTI 性格测试是什么讲起，包括它对汤峥嵘的影响，如何把这套理论付诸实践，他基于这套理论的思考。从个人职业性格延伸到“企业性格”，发散思考企业文化与价值观。
+
+以下为访谈对话。
+
+什么是 MBTI 性格测试？
+
+极客时间：我们就从你最想聊的性格分析开始吧，你怎么看性格对人的影响。
+
+汤峥嵘：我特别想讲一讲性格分析，人对自己情绪的管理。我之前做过一些管理培训，我也会让大家做一些性格测试，用的就是 MBTI 那套比较传统的性格分析方法。我发现，十个技术人里可能七八个都是一类性格，叫 ISTJ 型，我自己也是这种性格。
+
+这种性格的人，特点就是很客观，很理性。但是太理性的人往往容易陷入一个误区，认为只有理性的判断是靠谱的，非理性的判断都是不靠谱的。事实上很多人的非理性判断也是靠谱的。恰恰是因为你没有机会去锻炼非理性层面，你的非理性判断才容易不靠谱。
+
+那么是不是理性的人总是在做理性的判断呢？
+
+有一种理论把大脑分为理性脑、情绪脑和本能脑。或者可以简单地分为理性脑和非理性脑。我们以为总是理性脑在做决策。但真实情况是，绝大部分时候是非理性脑在做决策，而理性脑负责把决策合理化。所以有人形容理性脑是非理性脑的下级，它就像 CTO一样，责任是把CEO的决定合理化和逻辑化。
+
+所以越是理性的人，一旦犯了错就越固执。因为他逻辑性很强，总能给自己找出理由说自己是对的。这里说的“犯错”，通常是不那么绝对的错误。如果是特别明显的对错，通常也无法找理由了。
+
+你可以理解为我们人是由一堆传感器和一个处理器组成的。传感器负责捕捉各种数据，处理器负责用算法对数据进行计算并得出结论。所谓理性的人，偏向用足够多的数据得出逻辑上相对合理的结论。所谓非理性的人，就是在看起来数据不够的情况下，仍然可以用他们擅长的算法得出他们认为合理的结论。但在理性人的眼里，这些结论既缺乏依据，也缺乏逻辑，往往认为不靠谱。所以两个性格之间就容易产生非常大的沟通障碍。
+
+其实无论工作还是生活中，很多重要的决策，是缺乏数据和逻辑的。否则，创业什么的也太容易了，照着数据逻辑做就行了。就是因为你不知道未来啥样，你也不知道哪条路是对的，这时候就要靠你的非理性思考去做决策。
+
+说起创业，我现在做的智能穿戴产品就是通过编织在服装内的传感器，来长期获取人的生物体征数据，从而来量化人们在各种生活场景下的健康、情绪甚至性格。现代科学和医学已经对人的神经有了非常多的研究。例如人的心跳、呼吸、眨眼、出汗、肾上腺分泌等各种生理反应是非常底层的。控制这些生理反应的不是我们的大脑，而是自主神经，也叫植物神经。我们现在已经可以通过智能穿戴获取的数据来测量人的植物神经。这对于我们了解自己非常重要。我后续会多分享一些这方面的内容。
+
+极客时间：可以再简单介绍一下 MBTI 性格测试，以及 ISTJ 型人格？刚才只是笼统地聊了聊。
+
+汤峥嵘：MBTI 是一套非常流行的职业人格评估工具，有4个维度，每个维度都是两种性格，分别是：外向（E）和内向（I）、实感（S）和直觉（N）、思考（T）和情感（F）、判断（J）和认知（P），不同搭配组成最后的 16 种性格。这四个维度我们分别说一说。
+
+
+
+第一种，内向和外向。因为这是翻译过来的词，所以跟我们平常说内向外向有一定的相似，但也不完全相同。它的核心是说你的精力和注意力是对外的还是对内的。
+
+内向型的人比较喜欢读书，喜欢一个人去获取外面的信息，大部分爱读书的人都是比较典型的内向人。外向型的人喜欢跟人聊天获取信息，喜欢出去走走，他的信息从外面听来的可能比较多一些。
+
+内向的人一部分是不善于表达，但也有能表达的，只不过讲话容易累。这个特别有意思，曾经我上过一门课，有个老师很能讲。但是最后他问我们：“你们猜我是什么性格？”我们都猜他是外向，但他说自己是一个极度内向的人，他说我讲课是很累的，但我给自己找了一个方法：每讲两个小时，就得消失个 15 分钟，去喝咖啡、看会书，给自己充电。
+
+现代社会对我们的要求可能和我们的性格是冲突的。比如外向型总体比较受欢迎，因为无论在工作还是家庭中，沟通都是非常重要的。内向型的人如果了解自己的性格，就知道有时候需要切换“性格”来适应场景。有点像戴着外向的面具扮演角色。中间过程或许阶段性地休息一下。当角色扮演结束后，最好还是回归到自己本来的性格。最怕的是我们不知道自己的性格，还以为这个面具就是自己的一部分。时间长了，摘不下来了，但又很痛苦。
+
+我有个特别有意思的案例。以前途牛的一位创始人是典型的外向型。他特别喜欢出去看其它公司、其它行业是怎么做的。他每周要出去个三四天左右，在公司就只呆一两天，回来他就跟我们聊，在办公室把他看到的事情写在白板是给我们讲，我最开始就觉得他这样特别乱，没啥条理，因为像我这个性格的人，特别希望听逻辑和条理清晰的事情。
+
+后来我就理解他了，因为他是个外向型的人。他花两个小时和我们互动之后，能把出去这趟的信息都整理得清清楚楚。结束的时候，白板上总能出现非常有逻辑和条理的结论。他需要通过和他人的互动来获取信息、整理思路，甚至做出关键决策。而我作为一个理性的人，可以帮他做梳理，在这个场景下我是个很好的工具。当我知道我俩不同的时候，配合就非常好了，我也不觉得痛苦了。
+
+第二种，S 和 N，S 叫做实感型的，N 叫做直觉型的。我是实感型的，做决策是要数据的。直觉型的人就是凭直觉来做决策、做判断。
+
+我做决策的时候，需要数据来支撑，信息不全的时候，我是不容易做决策的。以前我做CTO的时候，有时候老板会希望我马上对一个新产品新应用进行评估，希望我马上给出上线日期。我就跟老板说，我是内向+实感型的人。我不像你，能通过讨论，凭直觉做判断。我不行，我需要一个人静下来，用数据仔细算一算。遇到这种沟通问题，其实就是给对方讲清楚，我的处事逻辑是怎样的。
+
+假设人脑里真有“电路”，往往直觉型的人，他的 CPU 的速度要比实感型的人快，他的传感器也非常多，很快就用自己的一套算法和自己获取的数据预测出一个结果。在他自己的运行体系中，这个可能是靠谱的。
+
+在我们实感型的人来看，这就不靠谱嘛，因为我速度比他慢，比如说他一秒钟算完了，我可能要算十分钟，甚至一个小时。你就会想，这不可能，他怎么那么快算出来？他肯定缺失了很多数据。但是事实上，他可能经过长期练习，就有这个敏感度和自信。
+
+这方面也有例子，比如说程序员去赌场赌博，我们都是相信概率。以打德州扑克为例，第一轮，两张牌发完，有人说“我 All in”，这时候你肯定吓一跳，这刚叫牌他就 All in，那我不跟了。为啥？因为你信息不够了，算不出来，你只能放弃。
+
+那些直觉型的人或者职业打扑克的人，他就是敢做。我是认为，他也有获取一些什么信息，比如他看到我这个人的样子，看我的眼神就知道我是保守的，他只要吓唬我一下，那我肯定就不跟了。从这个角度来讲，他跟我们想的概率不是一个层面的。他的感觉比我更灵敏，信息量就比我大，也就是数据维度比我们多，对我们进行降维打击。我们做程序员的人可能根本就没想到，根本连脸都不看，我就盯着自己的牌，而且我还以为这个就是所有的信息了，所以我们这样的人直觉就不够。
+
+很多S型的人总觉得直觉不靠谱，但是当信息不够的时候，你会发现N型的人靠直觉更靠谱，S型的决定反而不靠谱。
+
+我就是 S 型的人，我是比较喜欢用数据，但是现在随着年龄增长和工作的需要，我也知道某个决策该拍就得拍了，我要求我自己必须得靠一下直觉。即便自己心里知道这个是拍脑袋的，但也要相信自己的判断力，你越坚定，团队执行得就越有信心，也许这条路就走成了。
+
+第三种就是T（思考）和F（情感），我认为把它们翻译成理性和感性更好理解。感性的人基本上靠情感来做决策的。
+
+拿辞退人作为例子，我是 T 型的人，比较理性，我觉得这个员工不好就应该辞掉。但是让 F 型的人来判断，就会说你看你把他辞掉了，他没工作了，他怎么养活孩子、养活家？同理心让他得出的结论是不应该辞掉他。
+
+T型的人完全从逻辑进行思考，而F型的人同理心强。当缺乏充足证据和逻辑的时候，说服他人更好的方法也许是同理心和感性。
+
+第四种是J（判断）和P（知觉），解释一下，J 型的人是比较喜欢按规划、规则做事，P 型的人喜欢自由，比较天马行空。
+
+我是 J 型的人。比如我跟太太出去旅游，我就比较喜欢做好所有的准备工作，看好时间、做好攻略、安排好每天的行程，甚至规划好每个景点玩多久。如果我老婆说这个景点很好玩，想多玩儿一会，我也许就容易纠结。因为多玩一会是应该的，但因此也会打乱计划，影响后面的行程。
+
+讲出来都有点搞笑，就是对J型的人来说，去旅游景点玩儿，和玩儿完之后我把这个事打上个勾，那个勾的满足感或许更强（笑）。你就可以理解这个区别了，最终是一个人的满足感。而 P 型的人，他根本就对那个勾没有感觉，他就是喜欢无拘无束，天马行空。
+
+我有一次讲课，拿这套系统大概测了 30 多个人，不全是做技术的，还有做市场销售的人，竟然没有一个 P 型的人。显然是大家已经被工作改变了一点自己的性格，有的人最初性格说不定是 P 型的，但是因为几乎所有的工作都要求排计划，这个就导致大家必须改变自己，按规划、规则办事。
+
+J 型的人在工作中也有不灵的时候。比如电商公司的系统平时很稳定，但偏偏在 11.11 出现了系统宕机，这对技术人员是很大的挑战，甚至是最头疼的事。这种突发事件对于 J 型的人是严重的打击，因为不按他计划走，如果有很好的备案还好，如果没有，他马上就会慌了。这个时候再做决策就容易被情绪支配了，但是他的非理性部分又不经常练习，所以就做不出好的决策来。
+
+而这个时候，P 型的人就会跳到舞台中央来了，他在这时候状态都来了，或许能想出很多J型人想不出的解决方案。所以当出现突发状况时，公司要去用 P 型的人，大概他要比 J 型的人做得更好。
+
+极客时间：之前在一次演讲中，我记得你说没有找过女朋友的IT男不适合做管理？你还记得吗？
+
+汤峥嵘：是的，我认为女生中非理性思维的人多一些，男生中理性的人多一些，特别是IT男。IT男如果是没谈过女朋友，比较不容易理解非理性思维的人，做管理的话挑战就比较大，因为管理需要和各种人打交道。如果结过婚，甚至有养过孩子，可能会更好。有孩子的肯定知道，孩子小时候是不理性的，带过孩子后或许能理解什么是非理性思维。
+
+但是工程师的思维往往容易比较线性，不按照逻辑走的就认为是Bug，我要把你修复掉。我经常跟大家分享一个小经验。我给一个管理者出一道题，就能大概知道他的管理水平在哪个阶段。
+
+“假设有个员工离职了，找你沟通，你是老板嘛，你好不容易劝说他不离职了，你这时候的心态是什么呢？”
+
+一种心态是，谢天谢地，这个人终于这次不离职了，我希望他不要再提离职，至少三个月、六个月不要再提离职了。大部分技术转管理的人很容易有这种心态，因为说服人不容易，说完了之后，心里还是不希望他来找你了。
+
+另外一种心态是，我知道我今天只是暂时说服了他，他回去一想，可能还会再来给我提，我就等着他下次来找我，我早就准备好了，而且我跟他聊我还特开心，我还享受说服他这个过程。
+
+这是两种完全不同的心态。很可能后者比前者在管理水平上更高些。
+
+前者他认为提离职是个 Bug，Bug 修复了，不会再发生了。但是我们所有人知道，恰恰是提过离职的人更容易再提离职，从来不提离职的人，他不会去找你。所以呢，恰恰是这种 Bug 一旦发生，它可能复发率很高，你要用 Bug 的方式去修它，可能永远修复不了。
+
+而且，你已经成为一个弱势，你觉得理亏，没有管理好他，他要来谈离职了，你好不容易说服了，但气场是弱的。提离职的人或多或少能感受到这个气场，被说服就比较难。
+
+我们做技术的，包括我自己，肯定都是觉得要摆事实讲道理：你为什么提离职？你是钱不够还哪里不满意？反正一个个问题讲完，我一个个解决掉。
+
+但是通常是，当这种离职事件发生，别人给你讲可能不见得是真话，其次就算真话，那个人未必就是因为这一个原因，你想着把这个坎儿给他解决了，他就能不离职了？很难。肯定是一个非常综合的东西，都已经积累到今天，要提离职了。
+
+技术团队的人性格很相似，都比较理性。但往往理性的人容易冲突。大家都觉得应该自己的逻辑是最正确的，而且认为其他人也是同样的逻辑，所以都憋着不说，但是等到开始出现问题的时候，已经跟之前那个问题不是一个级别了，你再用这种修复 Bug 的方式去解决，就解决不了了。因为 A 问题产生了 B，又产生了 C，这么延续下去，你也不知道最后变成了一个多么复杂的问题。
+
+写代码就是跟系统打交道，每天面对的是电脑和程序，是没有任何情绪的，是纯粹的逻辑。每天训练的都是理性，而非理性层面长期得不到锻炼。很容易就会认为人也都这样理性。而实际上有很多人不是这样思维的，甚至理性的人在做判断的时候也会是非理性的。
+
+所以了解自己的性格挺重要的。了解性格的一种方法是用MBTI这样的评测工具。最近我们发现我们的智能衣产品也能帮我们我们了解性格，而且可以解释为什么性格是天生的。
+
+举个例子，你觉得我是急性子还是慢性子？
+
+极客时间：你应该是慢性子。
+
+汤峥嵘：所有人都认为我是个慢性子，但是通过测试心电，测出来我是个急性子。从心电图上我们能看到波形的高度和宽度，波峰较高，宽度较窄的，说明心脏对外界瞬间刺激的那一刻的反应特别快，特别敏感，这是一种人。
+
+另外一种人是波形宽度较宽，高度较矮的，说明他对外界的瞬间刺激反应时间比较长。对着这个模型，我们后来问了各种各样的人，是急性子还是慢性子，几乎全对。所以我们认为性格可能是天生的。
+
+我知道自己是急性子，只不过随着年龄增长，我在想办法让自己在做抉择的时候不要着急，所以你会觉得我是慢性子，但是我知道我的内心还是个急性子，这个没法变的。
+
+你了解了自己，更重要是接纳自己，你老想把自己改成个慢性子，可能就没救了，因为你改不了，碰到刺激时你的反应是变不了的。我对事物比较敏感，我对很多细节也比较关注，你说这是后天练习还是先天就有的？我觉得很可能先天已经种下，基因让我对这样的事情敏感。
+
+反过来，另外一种我们说“心大”的人，碰到相同情况他可能就觉得这不算什么事。
+
+极客时间：明白了，对于这套理论我还有些疑问，比如说你是 ISTJ 型，这里面实感型和理性、讲数据它们之间是不是有直接关系，假如你是个理性的人，那大概率也是实感型的人？
+
+汤峥嵘：从理论上讲，有可能你既是一个实感型的人，但是也是个感性的人，你很注重数据，但是你也很注重情感，这是也有可能的。
+
+但是从我们测下来的结果看，重视数据的实感型的人，和思考型的理性的人正相关性会更大一些。先抛开内向和外向这个维度不说，STJ 在程序员中估计是超过 50%的，这个我很有把握。但是呢，真正好的团队是性格越多样越好。
+
+极客时间：我也去专门查了这个性格模型，四个维度代表什么，分别是代表动力、信息收集、决策方式和生活方式，总体来说称为“性格”这个词还是太大了，内向外向、感性理性还比较好理解，像实感和直觉主要看是不是依赖实际的数据，这个还是有点抽象。
+
+汤峥嵘：我再试着解释一下，评判一个人是实感型的人，还是直觉型的人，主要看他关注细节、经验、数据等看起来实实在在的东西，还是关注模式、未来、感觉等看起来虚一些的东西。直觉型的人，我们说起来好像人家不靠谱，凭直觉做抉择。
+
+但是我认为什么叫直觉呢？第一，就是他的传感器比较多。第二，他的决策模型不用那么多数据。然后他自己也很自信，他能说服自己。核心就是，因为他是这个性格的人，他做这个决策时候他其实很有信心的。只是你作为另一种性格的人来看，不相信他凭借这么点数据，就能做出这个决定来，感觉很不合逻辑。
+
+但是你要理解，确实他的信息跟你获取的是不一样多，但他的算法跟你的也是不一样的，你的可能是百分之八九十的数据才能算出来，而他百分之二三十就够了。很多成功的人，成功的原因可能就是因为长期训练算法，从而算法比普通人优秀。当然肯定也会有很多靠直觉的人，天生算法不行，就被淘汰掉了。
+
+极客时间：也就是说这样的人长此以往，不是特别牛，就可能特别傻？
+
+汤峥嵘：是这样的。你说像马云这样的人，大家一开始觉得他做淘宝这事很不靠谱，马云那时候跟 COO、CFO、CTO，三个人说，我要去做淘宝，这三个人都反对，这三个人是从 03 年那个时间点下，用理性分析问题的。03 年的时候美国 eBay 已经是全球最大的C2C电商公司，而且收购了中国最大的做 C2C 的公司——易趣，那时候易趣在中国市场份额是95%。
+
+这个时间点，马云说做淘宝，理性角度看成功率很低，你不觉得这人是个疯子吗？他们四个人做决策，三个人都投票反对。但他觉得就要往那走。三个人明明告诉他这个事是不靠谱的。但是他把这个事做成了，他就是天才了，他肯定有他的决策模型。
+
+如果你总按直觉做决策，但没成功过，那就是另外的故事了。所以这样的人少，往往就被誉为天才嘛。
+
+极客时间：所以人的性格，或者说情绪会影响决策，我对你前面说的“你越坚定，下面执行的人越有信心，也许这条路就走成了”。这个逻辑还挺好奇的，怎么形成这种正向循环？
+
+汤峥嵘：很多时候，信心决定了做事情的方法，甚至是结果。一个老板做决策、引领方向的时候是否自信，这个其实关系到团队的稳定。一个真正的牛人在面对未知时该怎么做呢？他要先把自己给“欺骗”了，只有让自己彻底相信，才能在对外表达的时候让人信服。
+
+再比如，你要决策准备在一家公司继续干，还是换个工作，无论你做哪个决策，做完决策这个过程中，如果你发现自己水平提升了，这就了不得了，你会给自己暗示，我这决策很棒很好，接下来做事又做成了之后，你就形成正向循环了，自信心也就越来越强了。
+
+极客时间：还有另外一个问题，不同的性格搭配，会不会决定某个人他适合去做管理，还是适合在垂直的方向上发展？
+
+汤峥嵘：我觉得肯定是有，比如说管理的人，我是觉得首先外向型的比较好，直觉型的人比较好。但这是针对“管理人群”这个模糊群体的大致推测，但你让我今天我做个归纳：什么性格的人就适合做 CEO，我觉得这肯定不靠谱。回答这个问题，我还是数据不够。
+
+因为性格只是一个方面的数据，但他的经历，做过什么事情，是否做过非理性的决策，这些真实数据你并不知道。
+
+互动时间
+
+关于 MBTI 性格测试的基础信息，先聊到这里，下一节我们会继续聊这套理论对汤峥嵘的影响。你知道自己是什么性格吗？欢迎在留言区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/02个人性格影响“企业性格”，企业文化离不开人.md

@@ -0,0 +1,125 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            02 个人性格影响“企业性格”，企业文化离不开人
+                            最开始接触这套理论是什么时候？
+
+极客时间：我们接上一节的问题聊，你最开始为什么会关注、重视MBTI这一套理论呢？
+
+汤峥嵘： 原因是为了提高情商，我现在要做的事情就是学习这些东西，这样我就可以去理解别人，通过这样的方法提高情商。
+
+什么叫高情商？就是能够理解他人，站在他人的角度思考问题。有的人天生就很擅长，但我们做技术的人可能很多是智商高，情商低。因为跟系统、代码打交道不需要情商。
+
+我慢慢觉得理解别人很重要，但理解别人又挺难的，我们可能总觉得身边人不靠谱，就自己最靠谱。这样的想法其实要改掉的。什么叫靠谱？他的做事逻辑自洽的时候就叫靠谱。
+
+极客时间：怎么理解这句话？
+
+汤峥嵘：就是他的决策，和你想法不一致，但是在他的这套系统是一致的。
+
+比如说直觉型的人做决策的时候，他内心都是很真实的。举个例子，假设早上碰到老板，他今天很开心，他觉得很久没和你一起聊天吃饭了，于是就说今晚有空吗？咱们一起吃个饭。那像我这样性格的人，我一定会把这件事记到日历上提醒自己。快到饭点，老板突然跟你说“哎呀不好意思，我忘了今天已经约好和另一个人吃饭了”，这个时候，你可能就会很受伤，因为你为了这顿饭把别的局推掉了。
+
+但你理解了老板的性格，你可能就知道了，在他见你的那一刻，突然想和你吃饭这个决定是真心的，他只是不习惯看数据，喜欢靠感觉做决策。他的决策虽然是错的，但他的初心未必是坏的。这个时候，我们能心平气和地理解这个人，你就不会误解了，也不会把这个事情想得很严重，这个很重要。
+
+极客时间：这个例子里，老板做事的方式感觉有问题。那换个角度，假设下属约老板吃饭却爽约，你会觉得这个人不靠谱吗？
+
+汤峥嵘：我们经常会给别人贴“靠谱”“不靠谱”的标签，因为职场对我们的要求应该都是这样的。但理解别人就是理解世界的运转，对你自己内心来说，你就更有包容性，不容易被伤害。拿刚才的例子，老板爽约，我们很容易被伤害，这是别人用他的错误来惩罚你，何必呢？你自己可以决定“要不要被他伤害，要不要把它当成一个事”。
+
+反过来说，假如一个人总是做诸如“爽约”这样的事，无论在职场还是人际关系里，他是很容易被淘汰掉的，也不用你来评价他如何如何。
+
+当你想通了这件事的时候，你就明白，他犯了错跟我没关系。我无非就跟另外的人约饭嘛，但如果你把这件事在内心中放大了，就会给人贴标签，最后你可能选择业务上不合作，事情性质就变大。
+
+有时候我们说所谓的情商低，就是因为不愿意去了解和自己不一样的人，就老是伤害自己，老是自己痛苦。我们做技术的很多人都有这种小问题。就是生活在自己构建的一个乌托邦里，就认为世界上只有 ISTJ 这一种性格的人。
+
+极客时间：哈哈，你讲这些，我们平常就会说“这人格局很大”，但真正能理解别人挺难的。
+
+汤峥嵘：所以，这其实是修行，你身边比较熟的人，你去多观察，多了解。你去看他做事情的动机、方法、原理，你发现他就是一致的。只是他的算法和你不同而已。不管生活还是工作中，多关注和你协作较多的身边人，不要陷在自己的逻辑中。
+
+极客时间：你是什么时候开始接触这套理论的？
+
+汤峥嵘：是我在阿里的时候，阿里的经历对我有非常大的帮助，后面我再细讲。关注这个是因为阿里给高管开过一门课，叫做《情商为零》，我当时第一个报名，因为我觉得自己情商不够高，这个课主要是讲怎么提高情商。
+
+讲完以后真的让我一下子醍醐灌顶，我一下觉得，原来这个世界上的人性格是这么多。我对这个课的记忆一直是非常深。我今天讲的，应该和那个老师讲的核心差不多。
+
+他说讲情商的目的是让我们理解这世界上很多不同种性格。我把这个称之为“理解他人”。我后来又增加了一条，“了解自己”。“理解他人”是指了解他人做事的原理。“了解自己”是指了解自己做事的原理。我认为一个优秀的管理者需要不断地提升“理解他人”和“了解自己”这两个能力。
+
+在“理解他人”方面，可以借助MBTI这样的性格分析方法论，也可以用其它的方法论。它们的价值在于让我们理解他人做事的规律和原理。这方面已经花了不少篇幅讲述了。
+
+在“了解自己”方面，MBTI这类的性格分析方法论可以帮助我们了解过去不知道的自己。了解自己性格的边界，了解自己在不同工作生活场景的的优势和劣势。在这个基础上，我们可能需要调整自己，优化自己。那么怎么调整和优化呢？这就需要另外一个概念：情绪。
+
+情绪是什么？情绪到底是主观想出来的，还是有底层的客观物质基础？情绪是如何影响我们做事的？
+
+我以前以为喜怒哀乐等情绪是我们人类独有的，最多也就是在一些高级哺乳动物身上有。但科学家的一个实验颠覆了我的认知。和人类相比，龙虾是一种非常低级的生物，有3亿年的历史。龙虾之间会相互战斗。败下阵的龙虾，通常会退缩。但是给败下阵的龙虾注入人类用的抗抑郁药之后，它居然会兴奋并重新战斗。这个实验说明，有些情绪是非常底层的，在非常低级的动物身上就有。情绪是有底层的客观物质基础的。
+
+那么为什么动物和人有情绪？一种观点是和进化相关。情绪是快捷键，可以让我们在一些场景下，无需思考就做出适当的反应。比如当我们的祖先遇到猛兽毒蛇等危险的时候，交感神经就会提高，从而导致心率上升、肾上腺分泌、瞳孔放大等。这个反应也被称之为战斗或逃跑反应。这种反应有利于躲避危险，让我们生存下来。当我们的祖先在安全的山洞里休息的时候，副交感神经会提高，从而导致心率下降、瞳孔缩小等相反的生理反应。这种反应可以让我们放松、生长、自我修复，也有利于生存。这些快捷键可能是在几百万年甚至几千万年的进化中也形成的。但在最近短短的几百到几千年中，人类几乎消除了这些自然界的危险。这些底层逻辑还来不及进化，于是就变成了焦虑、兴奋、烦恼等现代人的情绪。交感神经持续过高就是焦虑，副交感神经持续过高就是抑郁。
+
+之前讲过，一种理论把人脑分为理性脑和非理性脑。非理性脑就是靠情绪甚至生物本能来决策的。而我们很多时候都是非理性脑在做决策。决策后，理性脑负责把决策合理化。结合上面的情绪理论，我认为非理性决策的模型可能是这样的。当我们遇到一些不确定性问题的时候，我们的情绪会首先做出反应。这种反应是非常底层的，是为了让我们逃避危险，因为不确定性就等同于风险、危险。这种反应表现为焦虑、兴奋、紧张等各种情绪。同时，非理性脑快速启动，做出了有利于逃避风险的决策。而理性脑总是慢半拍，于是只好把这些决策合理化。这就是为什么我们明明知道应该怎么做，明明知道第一性原理是对的，但我们做起来的时候总是做不到。因为情绪替我们做了决策。
+
+因此了解自己的情绪就变得很重要。如果我们能识别自己的情绪，或许就能识别出我们的决策受到了情绪的影响，或许就能强迫理性脑去参与决策。我相信识别自己的情绪甚至管理自己的情绪是可以练习的，但难度肯定不小。特别是识别情绪，标准到底是什么呢？每个人对情绪的定义可能就不同。怎么定义紧张和放松？能否量化呢？
+
+我创业做的智能衣产品，就能够24X7不间断收集体表的生物电数据，然后通过后台大数据算法分析出交感神经和副交感神经的平衡。这对于我们了解自己的情绪或许很有帮助。特别是能帮我们了解睡眠中的情绪。大部分人是不太知道自己睡眠时候是什么样的。
+
+发散思考：企业文化与价值观
+
+汤峥嵘：说到人的身体数据，人的性格，我还想发散讲一点关于文化、价值观层面的事情，看你后面也有这个问题，就在这解答了。
+
+其实我刚到阿里，一开始对阿里的文化是有点排斥的，甚至不愿意接受。因为我在美国工作了很多年，从来没经历过这么大力度推行价值观文化的公司。但后来我变成了阿里文化的拥护者、推广者，包括我后来去途牛、VIPABC，都在推广这个文化。那个年代很多年轻人没有所谓的信仰，缺乏一套对价值的认知体系。而在做互联网这种新模式时候，会遇到很多新问题，没有前车之鉴。什么是对的？什么是好的？什么是应该做的？阿里价值观文化的意义在于可以指导年轻人去做具体的价值判断。
+
+现在，我的想法又有些不同了。经历了多家创业公司后，我发现阿里的文化很难复制到其它企业。一旦尝试复制就会变得很虚，很难落地。我就在想，既然人的情绪是有底层物质基础的，那么企业文化是不是也有底层的客观规律和数据基础？
+
+我觉得企业很像人。企业的文化很像人的情绪和性格。前面讲过，人在紧急情况或不确定性问题面前，情绪可以比理性脑更快地做出反应和决策。同样，企业对于外界的反应，很多时候来不及或者无法由扮演企业大脑的管理层做决策，那么就要靠企业文化和价值观。人在遇到相似的情况总是发生相似的反应。这就被描述成了性格。比如看到稍微恐怖的电影就害怕得心跳加速，就被称为胆小。看到美女就兴奋得心跳加速，就被称为好色。企业如果在相似的情况也总做出相似的反应，那么就可以被称为企业的性格了。
+
+极客时间：所以企业文化和“企业性格”有关，企业性格是什么样子的呢？
+
+汤峥嵘：企业的文化和价值观往往指的是企业希望自己的变成的样子。因此很多企业会把文化写到墙上，希望大家做到。而企业的性格是指在遇到真实问题时表现出来的结果。
+
+企业肯定都希望能做到完美，对不足的地方往往是希望复制其它优秀企业的文化。
+
+例如阿里有个“拥抱变化”的价值观和文化。阿里做得比较好，我认为有外因和内因两层。外因是当时外部环境在倒逼。做了B2B，马上要做淘宝和支付宝。几乎是完全不同的商业模式，而且是新模式。但人才不够啊，外面也找不到，那只能内部调整，拥抱变化。内因是轮岗做得非常彻底，彻底到把技术总监调整为人事总监这种程度。轮岗的人心态积极、正向。管理者充分支持新人，坚定业务目标。有意思的是，拥抱变化的背后，恰恰是团队对方向的认同和坚定。拥抱变化靠的是不变的目标。当然这个最终能沉淀下来，是因为不断有好的结果和回报，信心也就不断建立起来了。后面再遇到同样情况时，已经不再需要管理层做决策了，拥抱变化已经变成了自然反应，变成了性格。
+
+再例如大家都知道谷歌有鼓励创新的文化，允许员工每周花20%的时间做自己想做的事。这个虽然一直有争议，但既然能沉淀下来，也是因为不断有好的结果和回报。很多优秀的产品都是从这里冒出来的。
+
+但其它企业很成功的文化和价值观，不一定能复制到自己的企业。
+
+拥抱变化的文化，很容易因为管理层缺乏坚定的决心或者员工的强抵触心态而失败。创新文化很容易因为产出过低或者过于自由与缺乏自律，而坚持不下去。总之，外部环境是否有利造就成功案例，管理层是否能长期坚持，员工是否能积极执行，都会影响文化和价值观的落地效果。
+
+我认为和情绪一样，文化和价值观看似是虚的，但有着底层的逻辑和规律。因此我在思考打造文化和价值观的时候，应该怎么去找逻辑找规律？
+
+首先要总结出团队的性格。团队的性格不是每个成员的性格简单叠加而成的，而是这些性格的组合在不确定性问题面前的反应。因此要动态地分析。比如9个实感的人与1个直觉的人组合在一起，未必是实感型的团队。如果那个直觉的人负责做决策，另外9个实感的人负责把决策理性化并且执行出来，而且多次成功，这个团队的性格就是直觉型的。
+
+其次是利用团队性格，打造合适的文化。一个偏直觉的团队比较适合打造成拥抱变化或者追求创新的文化，一个偏实感的团队比较适合打造成客户第一或者质量至上的文化。用性格去打造对应的文化，应该比复制其它公司的文化要容易成功。
+
+极客时间：我试着去总结一下，首先，了解自己有一些方法，对自己性格的了解是很重要的，性格不同对你做决策，和世界交互都是有很大影响的。但是因为这四个维度其实是有区间的， 0-100 的百分比，比如很少有人是 100%内向，可能会落在某个区间内，而且毕竟是主观题，随着时间的推移，也许选择也会改变，所以 MBTI 这套性格测试其实它不是一个科学。但我们完全可以参考。
+
+汤峥嵘：关于它是不是科学，有不同的观点。我认为科学的方法论是先提出一个理论，之后通过不停做实验去验证。如果实验数据和理论一致，那么理论就暂时成立。如果实验数据和理论不一致，那么理论就要被修正甚至推翻。
+
+MBTI是有一套理论，也有一套用问卷做实验的方法。但它无法验证。因此我认为它不算科学。但它是一套自洽的体系，蛮像哲学。
+
+为啥我会比较喜欢用这套体系呢？第一，大部分被测试者对结果比较认同。第二，在我们程序员这个人群中，ISTJ 或 ESTJ型非常多，很符合我的分类方法，说明大家思考的方式基本上是一样的。也就意味着，我们这些人做决策的时候也是差不多的。第三，利用我们创业的技术，有可能把原本无法量化的性格进行数字化，从而去做验证，或许也能成为一门科学了。
+
+平时是怎么用这套理论？
+
+极客时间：我还有个问题，关于这块，你刚才有讲，在阿里的时候学的这门课，学完之后，对你非常大的启发，经过这个启发之后，有哪些具体的行为、改变可以再聊一下吗？
+
+汤峥嵘：具体的行为我想想，开始肯定是在阿里的时候，我那时候又做技术又做管理，针对团队：我给他们都做了一遍性格测试。那时就已经发现，原来我们很多人性格是一致的。我记得那时候我们还专门找了几个跟我们不一样的性格的人来做对照。
+
+这个测试做完之后，不但让我了解了团队的性格，也让所有的做技术的同事感觉更近了，认可度更高了。后来我在其它公司做技术管理，一直坚持做团队的性格测试。
+
+所以我建议，你做管理，有机会的话，用这套体系去测一测周边人，去了解跟你合作的人是什么性格，同时你也要明白，两个性格一摸一样的人不见得就一定是合的来的，俩急性子碰一块，一旦闹恼了，那不是更着急了？就这个道理，性格一样的人不见得就是合得来。
+
+我前面说过，“理解他人”是理解他人做事的原理，这是终极目标。一旦理解了他人做事的原理，我们就完全可以解释他们的历史甚至预测他人的未来了。但在达到这个终极目标之前，你不一定能理解其中的原理，但至少可以理解一个事实，就是与你不同性格的人，对于同样的问题，反应可能是完全不同的。他的反应不是针对你的，而是他性格中的一部分。
+
+这时候，假如他犯了错误，你可以为这个“错误”找个理由，去原谅他，这是个好事。第一，这个世界在你眼里可能更容易产生亮点；第二，真正就是因为你想通了，你明白了人与人的不同，你找到一个理由，给自己舔伤。我是这么过来的，自己要多练，说的不好听就是，你的麻木的能力就变大一点了，对所谓的“伤害”就无所谓了一点。
+
+真的要开始理解别人为什么会这么做事，否则，特别是像我这样性格的人，就很容易陷在自己的世界里。
+
+互动时间
+
+关于职业性格的内容先聊到这，最后，我也想留个小问题给你。汤峥嵘发现自己深度睡眠为 0 后，很长一段时间，他开始每天关注的睡眠数据，去医院检测，以及用他们现在的心电衣产品做监测，通过调整室温、调整睡姿等（相当于每天变一个参数），最后把自己的深睡眠硬是给提升上去了。
+
+你有通过深度了解自身数据，从而改变自己的经历吗？欢迎在留言区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/03闲话家常（一）：半工半读的留学生活.md

@@ -0,0 +1,141 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            03 闲话家常（一）：半工半读的留学生活
+                            编者按：从这一讲开始，我们进入第二个模块：职业成长。回顾汤峥嵘从美国留学至今的经历。美国求学工作十四年，他经历过职业快速成长期，也曾有迷茫。其中留学生活是他真正蜕变的开始，从清华退学，选择去美国留学是他人生中一个重要选择。这一节我们主要跟你分享汤峥嵘半工半读的留学生涯。
+
+极客时间：你当年从清华退学去美国留学，关于这段经历，还想跟你聊聊细节。为什么会选择冒这么大的风险去做这样一件事情？当时是怎么考虑的？
+
+汤峥嵘：我们那时候想出国的人还挺多的，尤其像清华的，比我们出国早的，有一批人是靠着李政道发起的 CUSPEA 项目（China-United States Physics Examination and Application，中美联合招考物理研究生项目），拿到美国那边大学的奖学金去读书。那时候大家基本没有能力负担出国的费用，都是靠奖学金。
+
+我为啥离开清华呢，这件事现在看来就太不理性了。我已经有了一个不错的大学了，但看到清华中还有一些更厉害的人，还在考托福、GRE，我也想去试试，就又在琢磨更好的事了，总是好奇，总是不满足，就是想做更厉害的事情，开始的想法就是这么简单。
+
+这个事情回到咱们前面说的“理性”“非理性”决策来讲，就是因为，一种自我优越感的非理性的情绪影响了我，我就觉得自己挺优秀的，就想去尝试更多东西，有时候这个情绪对你是好事。所以我说非理性是很重要的，它给你的是信心，让你坚持选择。如果我冷静下来，仔细琢磨这事，肯定感觉这事不靠谱，那没有后来了。当然这个事的结果不错，我觉得靠的是运气。
+
+所以做这件事的动力就是因为自己想去尝试更多有挑战性的事情，就是这样。
+
+极客时间：所以那个时候，身边有一批人就在准备出国了。
+
+汤峥嵘：对，很多都是大三大四才准备出国，因为要毕业，再去申请研究生。我算是在我们年级中比较早的，开始准备的时候才大二。
+
+当时整个学校里面，比较有气氛，像俞敏洪的新东方那时候就是在清华里面到处办课的，现在回想起来也挺怀念那种感觉。那个年代年轻人是非常有想法的、有朝气的，无论做什么事情，大家都觉得好像可以做成一样。现在正好有点倒过来，开始躺平了。
+
+极客时间：这一点确实有所体会。当时你是拿到了奖学金，然后出国留学吗？
+
+汤峥嵘：对，我那个时候申请的是国外的本科。奖学金那时候是这样的，第一，你如果是研究生，你给老板干活，老板给你发工资，这样变成了一种奖学金的形式，大部分是读了研才有这个，当时很多人是等到毕业了再去申请研究生。
+
+第二，那个时候比较容易拿奖学金的是纯理科类的，就是数理化生这些比较好拿。我学的是计算机，计算机算是工科，就非常难拿，我后来是拿到了一个学校的半奖，不是很多，但当时也觉得不错了。
+
+极客时间：那时候是特别想出国，还是说想去个更好的学校？
+
+汤峥嵘：可能都有，那个时候真的不是特别明确到底要做什么，但是呢，我是学计算机的，肯定有一点我知道，就是中国的水平跟美国还是差的比较远。那时候清华计算机系是中国最好的计算机系之一，但我一出国就感觉，咱们的硬件水平不知道差到哪里去了。
+
+极客时间：你看到的这个差距都体现在哪？
+
+汤峥嵘：我是 91 年到美国去读书的，那会每个学校的学生都可以在一个开放性的机房用计算机，里面大概几百台 486，全是 486，免费可以使用。因为我们有时候要交作业是要打印出来的，你写一篇文章，一按打印键，在另外一个打印室里就可以领到你的东西了。那时候就觉得国外的硬件条件实在太好了。
+
+那会清华的计算机系只有两台 286。我们记得大一学编程，我们有个词叫“上机”，用的都是小型机或中型机，学校给每个人分配一点机时，从登录进去那一刻它就开始给你计时了，你就在里面编程，编完程退出来，给你算你今天用了多少时间。我记得很清楚，我们那时候第一次学编程，整个一学期就只有一百个小时的机时，还得包括你把程序通过键盘敲进去交作业的时间。每次作业都要在纸上演练很多遍才敢上机。
+
+但它有一个漏洞，它不是用到一百小时就马上给你停了，而是退出的时候才给你算多长时间。我们就是为了占点便宜，最后一次上机，半夜里看着时间过了一百个小时，也不退出来，就在那等着。那时候那里面也没游戏，啥也没有，但用超过了 100 个小时，我们就觉得占了很大便宜。相比之下，我们那时的硬件资源有多么匮乏。
+
+还有在美国，每个学生都有一个 Email 账号，我那时候在国外和我同学联系还是写信呢。后来我跟他说，我这都是用 Email，我要给你们发 Email 行不行？交流就方便多了。因为以前真的只是靠写信的，一封信一个来回得需要好长时间。
+
+然后他们就说，也有 Email，我给你发个 Email 地址试试，他们那时候是 IBM 格式的，Email 地址就像一个目录一样，全是斜杠。而我在国外用的就是咱们现在用的邮件格式，后缀是.edu。根本没法用Email交流。
+
+那时候国外和中国的硬件、软件差距真的非常远，从计算机那个角度来看，真的觉得美国是天堂，我们这太落后了。但是这么多年，回过头来再来看，我们中国的发展真的是很快。
+
+极客时间：去了美国后，你心情怎么样？
+
+汤峥嵘：先从去美国的这一段路讲讲，对我们这些连飞机都没坐过的人，这个开端注定不那么顺利。
+
+第一件事，我在日本转机，我搞笑到什么程度？因为没有坐飞机的经验，也从来没用过行李推车。我可能是把护照放到推车上，结果丢了，就在日本机场。
+
+准备要上飞机了，一看，我的机票护照去哪了？都不见了。我当时还算比较理智，第一时间想到去找警察。我一进去，所有人都站起来就给我鞠躬，有人问我需要什么。这点倒是对国外的印象不错。他们英语也不好，我英语也不好，我们就靠关键词交流。还没讲完，就看到有一个人跑进来说捡到一本护照，送进来一看就是我的，如果真丢那了就惨了，就卡在日本了（笑）。
+
+第二件事，到了美国，我先是飞到纽约，下了飞机，在行李转盘等我的行李，我看一个黑人就站在那把我的行李帮我拿出来了，我觉得还挺好，结果他张口就跟我要小费。当时完全听不懂。我甚至怀疑以前学的是不是英语。虽然听不懂，还是很容易猜出来是要小费，我也只能心疼的给了。
+
+你后面问我有没有孤独，我刚到美国，真的最大的问题就是我去的时候就我一个人，钱也不多，确实很孤独。我现在好多高中同学还有我的信，后来老同学们都跟我说，一看你就是很孤独，写了那么多信。我现在都能体会到那种感觉，你在学校里面，你会感觉这些建筑、草地、景色都非常漂亮。但是你心里特别紧张，因为我把学费交了就没钱了，完全不知道明天还有没有钱，所以我在美国打过各种各样的工，一边打工，一边上学。
+
+极客时间：上学的时候，你都打过什么工？
+
+汤峥嵘：最早我们都是在中餐馆打工，因为那些中国老板英语都不好，他们要接美国人的生意，就比较喜欢我们这种留学生，会讲英文。
+
+但那时候我刚去，英语还很弱，到了餐馆后，人家给我打电话点餐，我接半天电话也记不下来他点什么东西，把老板气坏了，说你到底是不是留学生，是不是大学生？我当时又怀疑我学的是不是英语了？怎么感觉他们说的我一句也听不懂。后来老板看我不行，就让我去送外卖。
+
+我在学校里也做过工，学校管理比较严格，留学生可以打工的种类很少，而且一个礼拜最多能打二十个小时的工。像我做过的，比如在餐厅里面擦擦桌子了，收收盘子了，这是一种。还有一种在自助餐厅，有一个冰激凌柜，我给大家挖冰激凌，我想反正是公家的钱，我就很慷慨（笑），很多女生都比较喜欢我的服务，因为我经常给她们挖一个很大的球，她们就很开心。
+
+那个时候打工经历对我帮助还是蛮大的，因为这就是接触社会嘛。
+
+极客时间：在美国的学习生活怎么样？可以讲讲你在大学里的一些学习故事吗？
+
+汤峥嵘：我希望在美国读两年就能毕业嘛，当时就得算需要读多少课，排一排课表。我记得大学第一学期，因为英语过不了关，我就尽可能学对英语要求不高的学科，比如计算机、数学，这些我都强。
+
+第一学期，我就选了一门心理学课，剩下的全都是理科。但是我后来发现学这一门心理学课的时间，比我剩下的课加起来总和可能还多，因为刚开始纯英文的，对听力各方面要求也比较高。但是我将来还想读研究生，所以还想拿个好成绩，最后这门课结果还不错，居然还拿到了 A。
+
+后来呢，我还是有大量文科的课是必修的，讲几个我觉得挺好玩的事，比如历史，要求我们至少得修两门历史，其中有个课叫世界历史，学历史对语言能力要求更高，我就很痛苦，后来我想了一个办法。
+
+我在国内学过中国革命史，我就想，那对美国人来讲，我们的中国革命史，就是世界历史啊。我就把我在中国学的历史课的大纲，翻译成英文，写了一份，然后拿给那个历史系的老师去看，说我学过世界历史了。老师居然认了，我的世界历史课就免掉了。
+
+另外对我来讲比较难的就是音乐了，属于艺术类的课。这个音乐课老师一上来，先告诉所有人成绩是怎么组成的。一次期中加一次期末，占总成绩的 30%，剩下的 70%是要听音乐会，写听后感。这一下难度就上去了。再加上听音乐会还是蛮贵的，幸好我们学校边上有很多免费的音乐会，或者专门给学生会留一些免费的位置，后来我全都是听的这个。
+
+其实音乐课对我来说受益很大，这个老师讲音乐史的时候，把音乐史、绘画史，建筑史一起讲，他说这就是一个历史。我现在都能大概背出来，比如说巴洛克时代的教堂做得都是非常工整（对称），非常繁华（点缀多、富贵）的，对应到这个时代代表性的音乐家巴赫，他的音乐也是节奏非常工整，但是旋律特别复杂。罗曼蒂克时代，音乐代表人物是贝多芬，当时的绘画风格和音乐风格也有相通之处。到了印象派时代，代表人是德彪西，他的作品不能听每个音符，要抽离出来听整体。很像梵高、莫奈的绘画，近看都是点，要站远一点看才能看懂。
+
+其实到现在我还不懂这些东西，但是他讲这些让我觉得很受启发，感觉这才是真正艺术的本质，让我们不懂的人也能知道，原来它的原理是这样子的。虽然在美国我学了那么多理工科的东西，但是恰恰这种文科的知识让我感到非常有意思，确实他们人文的东西讲得很不错。这些大概就是美国学习生活对我的改变。
+
+极客时间：后来你是怎么慢慢适应美国的环境的，不管是学习环境还是生活环境？
+
+汤峥嵘：开始我们中国人有自己的圈子，但是我想毕竟要跟美国人沟通，你得想办法融入美国人的圈子，还是有很多中国人跳不出来。首先，先过语言这关。第一个，我就看美国的那些肥皂剧，里面总有些笑声作为背景，听的多了，我就知道这个地方好笑，慢慢有场景感，这样我的语感慢慢就锻炼出来了。另外，中国的文化比较含蓄，英语从语言上是比较直接的，我也强迫自己调整过来。
+
+我当时还问过什么时候英语才能真正熟练，有一个人跟我说，你什么时候晚上做梦用英文做梦，你就过关了。刚开始做梦，梦里还是中文。
+
+另外一个就是我比较喜欢美国的橄榄球，因为我发现美国的男生除了谈工作，绝大部分都在谈橄榄球，橄榄球是在差不多在 9 月份到第二年 2 月份，主流的比赛又分大学橄榄球和职业橄榄球。到礼拜五，大家就赌一下，赌哪个球队赢。我觉得这个事特别有意思。大家周末看场球，看完了，周一再讨论结论，就感觉一周都有话题。我那时候就被他们带领着去看这个东西，然后跟他们就有话题可聊了。
+
+我也尝试过跟美国人聊中国的文化，因为文化差异比较大，我讲多了，他们也听不懂，或者也不感兴趣，当然有一部分美国人对全世界的文化都感兴趣，我跟这样的人就会聊很多。但是百分之八九十的人，就是关注自己的生活，每天上下班，哪也不去，生活特简单。我就尝试去融入这种生活，去了解他们的文化。
+
+极客时间：不管是学习还是打工，都要求你必须独立，这个经验是很宝贵的。除了刚刚我们聊到的你在美国的这些经历，还有哪些让你印象深刻的事儿吗？
+
+汤峥嵘：有一年暑假去纽约打工，当时找了个很奇怪的工作，是一个韩国人开的小超市，我做收银员，一般收银员都是女的，我开始不知道为啥让我去。去了才知道，在那上晚班，从晚上八点到早上八点，女的上晚班可能不安全。工作倒是很简单，就是收收钱。
+
+但是这个工作里面有几个很有意思的点，第一，管事的领导是巴基斯坦人，带了好几个移民和几个土生土长的美国人，我还记得还有个健身教练，负责切肉，有个泰国小伙负责面包，我没事就和他们聊天。他们觉得我很新鲜，因为之前他们超市里从来没有中国人。
+
+第二，我住的地方离我上班的地方挺远的，坐完地铁还得走一段路。有一次半夜回家，在路上，我远远看到前面有一个人，就觉得不太妙，再往后看，发现后面也跟了一个人，我就知道这俩人要堵我，我就赶紧往旁边跑。在纽约我经历的最危险的应该就是这么一次。我能看出来，这两个人就是要抢我，当时我还想，他们要抢点钱就给他们，也不至于把我怎么样，但心里还是怕怕的，就赶紧朝着旁边的街道跑了，我对地理位置的认知还是不错的。他们可能看我认路，以为我也是当地人，最后也没追上来。
+
+还有，我记得，我们那时候住的条件是非常差的，都是各地来的学生合租在一起。大家挤到什么程度？有人睡在壁橱里，有人分摊卧室，但我就是最奢侈，为什么？因为他们都是白天上班，晚上回来睡觉，我正好倒过来，白天整个大房子就我一个人睡。这个经历对我影响很大，整个暑期，接触的都是这种性质的生活，以前打工也没有条件这么差，那次的条件还是蛮差的。
+
+那时候留学生的条件普遍都很差，每到人家扔家具，我们就去捡，因为那会真的很穷。我先捡了个黑白电视，过几天看到有谁丢了个彩色电视，我再把彩色电视捡回来，这回我也可以把黑白电视丢掉了。
+
+还有我们的席梦思床垫都是捡来的，开始捡一个弹簧老化不太硬的，过两天又捡到一个比较新比较硬的床垫，就是因为经常有人会扔很新的东西。当时不觉得苦，为什么？因为他们扔的比我们国内的条件都好，那时候就感觉美国好发达，后来回到中国再看咱们发展的增速，真的很快，但 90年代的时候，差距还是蛮大的。
+
+极客时间：在美国的学习经历对你来说影响应该挺大的，必须要求你开始独立生存了，可以说说，这段学习经历对你的影响吗？
+
+汤峥嵘：最重要的就是教会我“自己做选择”，当时我最大的感受就是太自由了，一下子不知道自己应该怎么做，反而压力非常大，再加上我还要打工，所以说那个时候，人的成熟是非常快的，因为你要对学校的情况熟悉，要想办法存活。
+
+如果让我讲一些道理，我觉得，我们中国的大学生也好，年轻人也好，有一点需要提醒自己，你要努力去想办法去找机会。因为在中国，从小学、中学到大学都不用自己选，课也都是安排好的。在美国读大学给了我一次特别好的机会，就是要求自己，所有的事我必须得认认真真做选择了。
+
+这段经历对我未来的影响就是，当自己选择的路自己走过了，后面很多事情也不怕了，因为我知道所有事情都是自己前面选择的结果。
+
+极客时间：这和国内是很大的反差，以你的经历，你会建议在学校的学生应该怎么培养这种独立？
+
+汤峥嵘：咱们国内很多刚刚毕业的学生确实缺少独立的性格，比如找到工作，特别是去了大厂，他们自然会认为，公司还会继续培训。应届生一开始工作，很多人第一个问题都是，“咱们公司培训在哪？怎么培训，培训什么？”感觉还是没有离开学校，还是卡在学校的体系里。
+
+在美国恰恰是，在大学的时候已经没人带你了。我经常跟很多小孩子讲，我在美国找到第一份工作的情形，我刚去，老板把我带到我的座位上，说这就是你的电脑，这是你的座位，大概讲讲你负责的工作，我的第一份工作就是做互联网，老板就说这是我们的网站，你看看，这是代码，你自己看，然后就走了。
+
+到下班时候，我再观察着，看看大家几点下班走。到第二天我已经知道几点钟来上班，几点下班，中午跟谁去吃饭，我就清楚了，也就这点事。
+
+但在国内，大家就是往往喜欢看公司的流程是什么，需要别人告诉他规范，告诉他应该怎么干。
+
+但我还是觉得人要想办法越早独立越好。
+
+对于在校的学生如何培养独立的性格，我的建议就是去独立承担一些学校和家庭以外的责任。比如去餐厅打工，去当骑手，去开发一个App，去做一个公众号，去直播卖货。无论做什么，要有一个参与方都能接受的目标，并且你自己能为此负责。所以关键词是“独立承担责任”这几个字。因为要对结果负责，选择才变得重要。当这个责任要自己承担的时候，就不得不独立起来了。
+
+互动时间
+
+注：文中提到的 CUSPEA 项目，是指“文革”刚结束，彼时出国留学尚无渠道，申请美国大学必须经过 GRE 和 TOEFL 考试，而当时在中国根本没有 GRE 和 TOEFL 考试，中国学生也不知道美国研究院和大学招生的手续和规矩，这种情况下，华裔物理学家、诺贝尔物理学奖获得者李政道专门设计了 CUSPEA 项目，给中国留学生创造了这种暂时的、独特的、公正有效的留学渠道。
+
+你在学生时代经历过哪些，对未来成长有影响的事？欢迎你在评论区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/04闲话家常（二）：匹兹堡6年与硅谷4年工作经历.md

@@ -0,0 +1,123 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            04 闲话家常（二）：匹兹堡 6 年与硅谷 4 年工作经历
+                            极客时间：研究生毕业之后，你就留在美国找工作了嘛，之前也看到采访说，第一次投简历投了两百份，这个数量当时也算不少吧？
+
+汤峥嵘：应该是很多的，因为那个时候的简历是纸质的，要一份一份寄出去，光邮票也不少钱。美国的经济应该是在 94、95 年开始逐渐回苏，但是整体形势仍然不是很好，找工作并不是特别容易找的，我当时也做好心理准备了。
+
+留在美国的原因，一个是因为 90年代的时候，美国的工资水平，比国内还是要高很多，我的第一份工作就是四万美金年薪，肯定比国内要高。
+
+第二，因为正好经济形势也开始变好，我就看到了一些机会，包括我选择了互联网行业。这个选择有运气成分，但也有自己选择的成分，那个时候，我觉得我已经开始有意识地挑选自己的未来了。我在学校的导师他其中关注的一块就是互联网，但是在学校里研究毕竟是小范围，所以我当时就开始往互联网领域去找工作了。
+
+其实我投两百份简历的难度在于每份都做了个性化修改，这个是花了我比较多精力的，我当然不是每个都改了很多，但我确实是根据招聘的需求，匹配后对每份简历做了调整。
+
+我把我这个行为叫“过度努力”，我特别相信这个，我做所有事就是喜欢多做一点，我才放心。某种意义上这简历是为我自己做的，因为我也知道，我这么改一点也许差异不大。但我总觉得，这是我对这家公司的一个态度，我把我的简历按照他的需求做了个性化的调整，我的这份心意或许就能够被看见。后来到阿里面试，我也做了很多工作，这个是我的习惯了。
+
+这两百份简历花了我很多精力，但是最后找的那个公司也是一个很一般的公司，并不是理想中的公司。
+
+极客时间：这两百份简历后来有多少给你回信呢？
+
+汤峥嵘：不多，没几个。我大概记得这个公司给我回信之后，我就去谈 Offer，我问了人家能给到什么工资，人家说四万美金，我一想挺好，就去了，整个过程很简单的。我运气特别好，这家公司当时做的互联网模式，跟阿里巴巴最早是非常相似的。
+
+然后呢，这家公司里当时也没有什么特别厉害的程序员，我去之后，老板看到我很努力，很快就招了不少中国人，都让我来管理。这点我还是蛮自豪，第一，我利用了自己的能力，改变了他们对中国人的看法。他们一开始找中国人的原因可能是因为工资要求不高，后来发现我们的水平还不错，而且工作态度都特别好。
+
+第二，我最后做出的结果是远远超出老板的预期的。我去了之后，反正我的习惯就是说，我看程序写的不好，就顺手改了，其他程序员也愿意让我改，改完之后就变成我来维护了，后来到 80%代码都是我一个人在维护。
+
+极客时间：当时你的直属领导会怎么管你？第一任领导对你影响大吗？
+
+汤峥嵘：你说把我招去的那个领导啊，我觉得还好，他对我的职业发展是没有什么直接的影响。因为他不太懂我的工作内容，都让我自己来干，但这个工作机会确实改变了我的人生。在他身上直接学到什么没有？技术和管理方面的，大概没有。但是他用人是挺开放的，因为他们之前没有用过中国人，他尝试用了中国人之后，觉得不错，对我也很信任，这点很好。
+
+说起如何获取信任，其实特挺简单的。因为我们做的是一个美国的 B2B 网站，美国人也需要去找公司采购什么的，他们也开始尝试把信息搬到网上。我记得最开始，他们想做一个功能，就是鼠标移到美国的一个州，这个州就变亮了，颜色就不一样了，再往下一点，就能看到这个州里的所有公司和分类。我当时想估计网上也有好多可参考的东西，结果搜了半天，没找到，因为那时候互联网不是很发达，我就自己想办法弄。
+
+这个功能的原理很简单，50个州就是屏幕上50个多边形。鼠标的坐标位置落在哪个多边形里面，就让那个多边形变亮。但几乎每个多边形都是非常不规则的，要把50个多边形都标记出来，其实是个体力活。这是最麻烦的地方。我就吭哧吭哧地把所有点都标记出来，功能也就很快做好了。但老板觉得很神奇，感觉这个很酷，很好玩儿，对他们做业务的人来说，这种东西拿出去做客户演示的时候非常有用。你看，信任就是这样一点点靠体力建立起来的，没什么捷径。
+
+所以，你说他对我的影响是什么？也许我并没有直接学到什么，但我通过“独立承担责任”和“过度努力”，我得到了很多宝贵的财富。
+
+极客时间：还有一个问题，就是 95 年刚毕业那会，美国互联网发展很快，你在这样的环境中，对当时互联网的繁荣有哪些体会？
+
+汤峥嵘：那时候互联网真的就是太热了，就拿我第一个公司来说，我们那个公司就是运气不好，如果我们公司再晚两年做这个业务，我们肯定就上市了。我是 95 年去的，大概在 96 年还是 97 年的时候，我们找到了一个当时在美国可以说是非常牛的 CEO。
+
+曾经有一个软件，叫 Lotus 1-2-3，是一个编辑表格的软件，它是现在 Excel 的前身，Lotus 这家公司后来被 IBM 公司收购了， Lotus 的这个老板，就变成 IBM 的 2 号人物，很牛。但这个人因为自己一辈子做大佬，他不愿意在 IBM 呆着，他就从 IBM 离开了。不知道怎么就找到我们公司来了，就成了我们的 CEO。这件事让我们觉得很膨胀，觉得我们公司很牛了。
+
+他来了之后给我们吹了一通，说互联网怎么好，应该怎么做，然后我们就很兴奋。我们员工最兴奋，因为我们原来办公室是一个大仓库改造的。老板就说，咱们是做互联网的，咱们得搬到市中心，后来就找了个很高级的写字楼，搬进去了。一把椅子就九百美金，条件超级好。
+
+老板这人心还不错，因为我是带技术团队，他还帮我放到一个最角的座位上，两边能看到的风景最好，给我安排这么个位置，美国人叫“Conner Office”。结果我后来发现这个位置特别热，很晒，一点都不好（笑）。
+
+那时候老板为了把他自己的事业搞大，他又在波士顿买了一家公司，把两个公司合并了。这相当于我们公司一下子壮大，我记得我们那时候匹兹堡大概两百多人，波士顿那边也两百多人，加一起一下变成四五百人的大公司了。
+
+那时候我们经常要飞去波士顿出差，动不动就说你出差一周，花销可多了，都是住最好的酒店。后来烧了几个月钱，很快就烧完了。到最后一天，我们老板从家里给我们所有人开会，说，对不起，我们撑不住了，我自己还掏了一百万美金。公司宣布破产倒闭，要裁掉几乎所有人，留下几个人过渡。
+
+前面我也说过，因为代码大部分我写的，我就被留下来，整个公司就留五个人。那个夏天，公司由我们5人用最小的代价运营，寻找重生的机会。后来果然找到了买家，公司恢复到了之前的规模。
+
+极客时间：你在这家公司呆了几年？
+
+汤峥嵘：六年，一直到 2001 年，在 2000 年 .com 泡沫过了之后，我和我太太就一起搬到硅谷去了，从匹兹堡这个公司离开了。
+
+极客时间：在第一家公司你是从什么时候开始做技术负责人，开始做管理的？
+
+汤峥嵘：很快，应该是半年左右就把我提到了管理的岗位，但那个管理不是很难，因为工作内容都是比较清晰的，我的团队成员也非常成熟和优秀，我布置任务他们就干，干完了我就交上去，比较简单，我们还是挺和谐的。不用花很多精力管人，比如像现在还看看他们什么性格啊什么的，那会都没有的。
+
+极客时间：这段工作经历对你最大的影响是什么？
+
+汤峥嵘：这段工作经历给我打下了挺重要的基础，因为我自己就意识到，自己的技术能力还是蛮重要的。不管到哪，我是靠技术吃饭的，有了这个技术能力，公司倒了都不怕。
+
+极客时间：我看你在硅谷的 4 年经历了很多家公司，你在硅谷的工作和匹兹堡这段工作相比，有什么不同吗？
+
+汤峥嵘：在硅谷真是感觉有一大把机会，我在硅谷呆了四年，换了好多小公司，在硅谷这四年我应该算是比之前更努力了，但我觉得自己还是遇到了一些瓶颈。
+
+一方面，我不喜欢大公司，那时候硅谷很多大公司已经起来了，像谷歌、雅虎等等，但我还想找创业公司，我还拿过 Salesforce 的 Offer，那时候 Salesforce 还很小，但是因为离太远了，它在旧金山，就没去。
+
+我的性格就是不太喜欢大公司，因为你得遵守各种各样的制度。包括后来阿里发展的越来越大，我都觉得待着不舒服，所以我离开阿里也有一部分这个原因。
+
+但是我喜欢小公司也不是为了想去淘金什么的，那个时候对股票这个东西的概念还非常弱的。我不是在匹兹堡工作了六年吗，我们这家公司后来被美国的一家大公司买了，那家美国公司上市了，一上市，股票就开始涨，第一次股票发生在自己的公司身上，我才开始知道股票是什么，以前都不知道什么是股票。也曾经去买了一点，但买了就亏了（笑），因为涨到最高点，就开始跌。很多公司都是会有六个月锁定期，锁定期一过，大家就开始卖了。我们那时候也不懂，开始看着涨，就觉得肯定还可以无限涨，我就留着，最后跌到比自己买的价格还低。
+
+我后来对股票就没感觉了，也不过分关注这块的利益，包括后来到阿里都是这样的。我感觉这也是个好事。因为你对外界的感知当中，这部分被你过滤掉了，你反而不会痛苦。因为你不会把它当成一个评价你幸福的标准。
+
+极客时间：你在硅谷遇到瓶颈，具体是什么呢？
+
+汤峥嵘：这个瓶颈属于职业发展的迷茫吧。在美国那个时候我看到的程序员发展路径，一般是普通程序员到高级程序员，再往上就是架构师、CTO，大家比较追求技术路线的发展。
+
+我在第一家公司做到高级程序员，而且我同时还做管理，到了硅谷等于我又重新开始做程序员了。而且到了硅谷后我发现，大家对 Manager（经理） 这个岗位是很看不上的，甚至说是歧视，就是说这个人做经理了，肯定技术不行了，他们会是这么认为。
+
+我在硅谷换工作的频率，大概是每年换一个，到第三个的时候，我就变成是首席架构师了，满足了我心理上的期待，这公司后来对我做教育也挺有影响。
+
+我当时就比较迷茫，想将来是做管理还是往技术上发展呢？我内心中是想做技术的，但是，总觉得我曾经还做过 Manager，就还想回去做。我那时候都考虑过要不要再去读个 MBA（工商管理硕士）什么的，也在寻找方向。
+
+极客时间：刚好你提到在美国的教育公司，因为后来你也在 VIPABC 工作嘛，那在美国教育公司的经历，对后面的选择有影响吗？因为我看你在美国经历这几个公司有做教育的（McGraw-Hill Research公司），有做医疗（Neoforma公司）的。
+
+汤峥嵘：医疗那家公司没什么影响，因为我做的部分属于采购系统，核心不在医疗业务上。我以前核心做的技术就是订单系统，电子商务这个方向，这也是为什么后来去了淘宝，因为订单在电商中是非常重要的。
+
+这个教育公司呢，对我有一定的启发，这公司有意思的地方是他们做特别传统的教育，客户是美国公立的中小学。我过去是为了帮他们做互联网化，但是我也从他们那学到很多。我去了之后才知道为什么美国的教育比我们还是厉害一点的。
+
+这家公司里面 90%的员工是统计学博士，他们出的所有考题，都要做到不带偏见，啥意思呢？举个例子，考数学题的话，语文不能太难，因为这个孩子可能语文不好，不能让他题都看不懂，单词不认识。比如发现某个题外国人的答案跟别人不一样，他们就要怀疑这道题有文化背景的偏见。2003 年的时候，就已经做到了题目不能对人群有差异化。
+
+第二个，他们要想通过考题，筛选出真正的天才来，会根据每道题的答题结果，给你调整难度，那时候已经做得挺成熟的了。前几年国内在线教育中热起来的自适应考试，其实就是这个。
+
+当时我就在那家教育公司大概做了一年。然后 2003 年的时候我去阿里面试，拿到阿里的 Offer ，2004 年回国了，运气还相当不错。
+
+极客时间：回顾你在美国的 14 年，你自己有过总结么？
+
+汤峥嵘：我觉得在美国的经历可以分为三个阶段，学生时代是一个阶段，在匹兹堡工作是一个阶段，硅谷算一个阶段。
+
+前两个阶段，我认为自己在发展上是没什么杂念的，就是简单的一步步往前走。到了硅谷，我发现在发展上反而不容易，人越多的地方，你见到的企业也多、高手也多，人就开始冒出各种想法来了。我在硅谷看到了众多的机会，也看到很多人发财，我觉得人生在这种时候是容易迷茫的。
+
+极客时间：刚刚你说，第一份工作让你觉得自己就是靠技术吃饭，我想了解，你在美国经历的公司是怎么把员工一步步培养起来的？是公司培养还是靠个人的成长。你怎么看企业在个人职业成长中发挥的作用？
+
+汤峥嵘：我认为培养这个概念在美国是没有的，或者很弱的。美国的环境是个非常典型的不靠组织，而靠个人的风格，厉害的人会互相欣赏，他觉得你行，就会招你过去。我当初去硅谷，也是我之前在匹兹堡就认识的一个人，他也到硅谷工作，就把我挖过去了。
+
+你刚刚讲这个问题，我想澄清个概念，我们常常会说公司怎样怎样，公司对你好与不好，但公司是虚的。公司本身无法和你互动。真正影响你的，是公司里的人，以及发生在你身上具体的事。所以我认为不存在什么公司培养人的这个逻辑。不要简单的把个体的结果归结到公司这种宏观和抽象的概念上。公司的好与坏与个体的好与坏肯定是相关的，但未必有因果关系。公司不是学校，没有义务培养人，也不可能培养出人。以我的经历，我相信无论什么时候都要独立，靠的都是自己先把自己的事照顾好，周边人照顾好，这个非常重要。
+
+我经常讲，无论在任何大的潮流背景下，你只要足够优秀，总是有机会的。还有不要因为大环境热，某个领域热就去做这个，我自己的例子，到目前为止，我都觉得硅谷本身没有给我多少资源，反倒是匹兹堡这么个小的城市，这么个小的公司对我的提升无比之大，恰恰在这个小公司里，我发挥了自己的作用，但是在硅谷，机会那么多的地方，我就不容易想清楚自己的未来。因为每个成功的人都有自己的成功的方法，你也不知道那个是对的。
+
+我们现在比较容易得到一些宏观的信息，比如企业股票涨跌、行业形势等等，但是我现在越来越觉得，宏观信息对我们个体的指导意义不是那么大，除非你这个人做得事情就是要利用宏观信息，如果你不是靠宏观信息吃饭，那我觉得还是先把自己的事情想清楚，
+
+互动时间
+
+你对自己的职业成长做过总结吗？你从自己的经历中学到了什么？欢迎在评论区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/05从排斥到拥护，我眼中的阿里文化.md

@@ -0,0 +1,133 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            05 从排斥到拥护，我眼中的阿里文化
+                            编者按：从硅谷到阿里，开始于吴炯（阿里第一任 CTO）在清华 Email 群组发的招聘广告，彼时汤峥嵘对未来如何发展感到迷茫，遇到了瓶颈，而远观大洋彼岸的中国正高速发展，这些让他感觉心里痒痒的。面试通过后，阿里为他保留了一年的 Offer，2004 年汤峥嵘加入淘宝，工号为 2000多。
+
+2003 年，汤峥嵘对阿里不抱很大希望，因为那时 B2B 在美国已经走下坡路了，他并不看好。直到吴炯和他说阿里巴巴要做个类似 eBay 的业务，汤峥嵘觉得找到了兴趣点，那时还没有“淘宝”这个名字。虽然心系淘宝，汤峥嵘应该也没想到进入阿里之后，一方面被阿里文化洗礼，一方面配合组织调动，阿里 8 年时光，在 B2B 就待了 6 年，经历了从淘宝、支付宝、阿里国际网站、日本阿里巴巴，最后再回到支付宝、淘宝这样的过程，充满“拥抱变化”的阿里特色。
+
+回国初，作为淘宝主架构师，负责架构迁移工作，第二期的 PHP 转 Java，整个数据库结构重新合理设计，贡献之一是引入 SCM 体系，开始把质量体系做起来。刚从美国回来，第一感觉是条件很艰苦，7 月的杭州天气很热，空调经常坏，虽然条件艰苦，但做这个项目特别有意思，当时淘宝一天的 PV 是一千万，他们正在为能够支撑一个亿的访问量而努力。
+
+2004年10月，上层决策要把支付宝这个功能从淘宝拆出来，变成一个独立的网站，独立的公司，汤峥嵘被调去做支付宝，负责支付宝的技术，目标就是 1 月 1 号上线。说起来叫负责支付宝的技术，但其实是光杆司令一个。
+
+做淘宝架构迁移时阿里请了 Sun 公司（Sun Microsystems，太阳微系统公司，SUN 取自 Stanford University Network 斯坦福大学校园网的首字母）做咨询（Java 语言由 Sun 公司推出），因为支付宝技术没有正式岗位，汤峥嵘只好申请经费找Sun的外包。
+
+支付宝上线之后，汤峥嵘就被调到 B2B 去了，彼时 B2B 有三块业务，一个是国际网站、一个是中文网站、一个是 CRM。汤峥嵘前三年负责国际网站的技术，三年之后，阿里和日本软银合资组建了一家新的公司——日本阿里巴巴，汤峥嵘任CTO。三年后汤峥嵘重新调回支付宝和淘宝，最后从淘宝离职。
+
+阿里 8 年，对汤峥嵘之后的职业生涯影响很大，对阿里价值观从不适应到拥护，是惊讶于文化建设对调动人的积极性竟有如此大的影响力，他变成阿里文化的积极推广者。他认为阿里给他最大的价值是让他从一个工程师转变成一个管理者，积累了很多信心。
+
+我们聊了很多他在阿里的故事，从中你应该能看到汤峥嵘心态的转变以及他的思考。以下为访谈对话。
+
+对阿里价值观从排斥到认同
+
+极客时间：你说在硅谷的时候，感觉自己遇到了瓶颈。回国之后，那个瓶颈你觉得解决了是吗？然后从职业方向上，就更多的偏向管理了吗？
+
+汤峥嵘：对，我开始偏管理了。在硅谷我面临的选择太多，让我有点迷茫，不知道往哪发展。回国之后，走上管理这条路也不是我选的，因为阿里一下子给了很大的发展空间，即便有很多人竞争，大家都有空间，都能往上走，这对我来说是一个好处。另外，因为这个公司发展很快，我只要跟着它的脚步走，也不用想很多。你看我在阿里辗转了这么多部门，待了 8 年，但我觉得时间过得很快的，所以当时在阿里比在硅谷让我更喜欢。
+
+在阿里，主要遇到的问题就是要适应它的文化、价值观。我明显感觉到，在阿里从技术到管理的转变过程中，必然要走过文化认同这个台阶的，我觉得在中国，管理的一个重要部分是让团队的价值观匹配。
+
+在中国做管理是需要把人的因素考虑进去的，看起来好像管理成本高，包括我自己也分析过，我在阿里到后期，我起码超过一半的时间是在做管理，但是反过来你再想，这个时间是浪费掉了吗？我现在觉得没有浪费掉，为什么？对一个人了解更多，在合作的时候就有非常大的价值，知道这件事给谁干能成，而不是只考虑岗位职责这个单一维度。
+
+极客时间：从美国刚回来，对阿里价值观有个态度的转变，这个是怎样的过程？你也说过开始不太能接受阿里的价值观。
+
+汤峥嵘：我对人都是认可的，但我对价值观考核是不适应的，因为阿里价值观考核要占到总业绩的一半，我就感觉我做得再好，才得 50 分，另外 50 分看起来是非常主观的评判。
+
+但是后来深入了解后我就发现，做价值观的初心是非常好的，公司也知道我们可能不理解，那就花时间讲，让大家理解。领导也不厌其烦地给大家做培训，讲大量的案例，比如说“客户第一”，里面有一条叫微笑面对客户，有大量的案例给我们讲，我就被折服了。而且经过一段时间，我看考评结果，发现打高分的人就是优秀，打低分的人就是表现差。
+
+极客时间：后来你认同这种方式？
+
+汤峥嵘：我认同，而且我自己给团队做了一个技术版的案例。技术团队怎么算“客户第一”呢？比如公司大了，肯定会出现有人分不清 IT 部门和开发人员的区别，经常有人会找开发人员修电脑，以前有人就说这事你找错人了，去找 IT。后来，我给他们提了要求。
+
+我当时跟团队说，我认为正确的做法是这样，第一，别人有需求找过来，你是做技术的，有能力识别出这个问题，请你必须从头到尾跟到底，即便你不会，你可以拉着 IT 同事一起去，看着这个问题解决，因为你是知道 IT 部门在哪的。这个问题解决掉之后，你跟客户说，我们俩不一样的，他才是修电脑的，下次你找他就行了。这就是“客户第一”。
+
+这个案例总结出来，大家就理解了。我说你有什么委屈，这个世界上不懂电脑的人确实很多，你爸妈可能也找你修电脑，你不修吗？你其实是有能力可以修好的，只是你觉得大材小用，或者说你确实不会修，没有关系，你可以替别人找到专业的人。这个过程恰恰是给你一个机会去和客户建立一个很好的关系，因为我们大部分技术人员是面对内部的。因为你解决了人家的问题，说不定人家给你提需求的时候，就很照顾你，给你提一个很好的需求，同事之间的关系都是靠这种小事情维护起来的。这是双赢，你既解决了客户的问题，又给团队挣到了一个高分数，何乐而不为呢？
+
+这个很像美国的案例法，参考案例是最直接的。阿里很喜欢讲案例，也影响我后来一直比较喜欢用案例去讲事，我觉得特别有说服力。
+
+阿里有一句话说“为结果付薪，为过程鼓掌”，过程做得再好，没有结果的话，只是给你鼓鼓掌就好了，阿里还是非常结果导向的。但是结果做到了之后，阿里还要看过程，因为一个好的过程可以让好结果不停地复制，一个不好的过程得到某个好的结果也是偶然出现的，因为你方法有问题。那么同时考核业绩和价值观，就是同时考核结果和过程，各占50%。
+
+阿里文化对我的影响
+
+极客时间：咱们之前聊到阿里文化对你的改变，除了提到的《情商为零》的课程对你影响比较大之外，还有哪些让你受益的东西吗？这个部分还想再展开一下。
+
+汤峥嵘：可以，我可以稍微讲讲这些。第一，价值观考核，这个背后反映的是阿里对价值观的管理体系，怎么把绩效管理融合在一起，阿里想得比较清楚，它也一直花精力宣讲使命愿景价值观。我现在自己创业，体会更深，你要让我在这个事情上投入这么多，我都觉得确实是舍不得的，因为短期内很难看出效果。
+
+阿里从 1999 年就已经想到这个事，而且经过这么长时间的发展，已经做得比较深了，它坚持做这个事情，加上它业务又做得好，就形成了一个正循环了。我也反思，现在很多企业想要照搬这一套，但都不能完全成功。我曾经想在途牛、VIPABC 把这些东西搬过去，都不能说是成功的。所以我想这套东西可能就适合于阿里或者跟阿里特别像的企业，而且这套价值观的提出可能也只是适合 90 年代末 2000 年代初那个时代，我们刚刚进入经济快速发展时期，大家一切都是向钱看。
+
+现在呢，年轻人已经不再那么单独追求金钱了，更追求品质，现在再去做价值观肯定要与时俱进了，你再去讲以前那个就可能有点过时了。
+
+第二，我在阿里感受到“管理的温度”和“方法”，领导班子有办法让员工产生非常大的工作动力。比如说关明生（Savio，曾为阿里COO）早期是如何激励 B2B 的销售的呢？他个人很有文采，他就想了个办法，你达到某个级别了，他就给你写一首藏头诗，大家就觉得公司老板亲自给我写一首诗，这个是很珍贵的。我觉得这个就是特别“阿里范儿”的一个东西，别人很难复制，因为并不是每个老板都会写诗，都会做这种事情，这个是激励个人的方法。
+
+另外，他很早就考虑到怎么让销售组织变大，因为做得好的销售，那些人往往会转管理，那些销售转管理之后，他仍然会继续做销售，而且很有可能这个团队主要的销售额还是来自于他，这对团队发展来说不利啊，Savio 就强行要求不能这么干，把销售 Leader 的签单权重降低，甚至不算，就强迫这些人去培训带人，把其他人给锻炼出来。这是要承受压力的，比如说把 10 个 Top Sales 转成管理，一下这 10 个人的业绩就没了，对公司来说，就会承受一段时间业绩的下滑。他就咬着牙去推这个事情。
+
+阿里在管理上，这几件事对我的影响是很大的，所以从开始有点消极抵抗到后面积极拥抱，甚至到后来主动去推广，就是因为我认同了。
+
+第三个，对我影响比较大的，阿里把所有 P10/M5 这个级别以上的人，拉到一起，归到叫组织部的这么一个组织里。然后定期开会、培训、讨论问题。组织部这东西很显然是把我党的这套体系给引入到企业管理里了，我觉得这很好。《情商为零》这个课就是在这里学的。
+
+组织部对大家的要求是啥呢？因为你属于组织了，组织让你去哪你就得去哪。比如我属于 B2B 的，从法律上讲我是和 B2B 签的协议，你如果把我调到淘宝，我相当于从这家公司离职去另一家公司的。当然也会尊重个人意愿，但是这个组织部的存在就是想告诉你，从内心上你要和组织关系更近。
+
+极客时间：这个话题很有意思，刚好借着讲组织部这个背景，前面聊到你被调来调去，变过很多岗位嘛，你有觉得不舒服吗？
+
+汤峥嵘：刚开始我去的时候还没有组织部呢。开始是有不舒服的，因为我本来是看好 To C，拿的 Offer 就是去淘宝的，最后让我去 B2B，我肯定会有点不舒服。
+
+但是呢，第一，我觉得当时我也没有特别强的理由说，一定要怎么样，因为 B2B 也不差。假设那会有组织部了，组织部先发声的话，我可能转过去就更顺了，我可能都不会去跟陆兆禧（2004 年任支付宝总裁）再去争一下要留在支付宝。
+
+你放到西方要说搞组织部这种东西，相当于你没有自由了，可能马上人家就不干了，所以我觉得这也是中国文化一部分，在中国这种文化环境下，我们绝大部分人，还是比较愿意接受组织安排的。阿里是把中国文化、人性的东西充分利用起来了。而且它做得好的地方还有，整个氛围是比较透明的，大家公开讨论问题，我能感觉到那段时间的成长是非常快的。因为别人出现的问题，我可能也会遇到，我就可以提前借鉴了。
+
+刚才说到部门变动，这其实还是小事，我还算幸运，一直都是做技术的。很多人直接岗位就变了，技术变 HR 了，前台变销售了，销售变服务，跨度更大。但是即便变来变去，在不同岗位还能出色的人，就证明了他就是优秀，金子到哪都会发光。
+
+马云那时候也跟我们讲过这个道理，他认为一个人在某个岗位工作到两年左右，就会变得缺少创造力，因为他对周边都熟悉了，就不再那么努力，没有那么创新了。这时候就可以把他换到一个新的岗位，让他焕发生机。要是优秀的人他就会先想，到了一个新岗位，我怎么创新，怎么做得更好。
+
+这也是我在阿里换岗位的过程中，对我比较大的影响。要在比较稳定的时候去担忧危机，要在晴天的时候修屋顶。
+
+回到组织部这个点，如果说其他公司或者团队能参考这种方式，把公司一群比较核心的人放到一起，让大家能够互相碰撞分享，凝聚力也会更强。像我们搞技术的人可能对业务人员的经历不清楚，其实业务人员经历的问题是最多的。通过这样的方式，技术人能更了解公司情况，从技术上也能做好准备了。
+
+极客时间：后来你在途牛，或者 VIPABC 有用过组织部这套思想吗？
+
+汤峥嵘：这个没有完全用，我还得补充说一说能运行组织部的基础，在途牛、VIPABC 很多基础都没达到。能运行组织部，首先公司的规模得比较大，比如阿里那会已经分成三个不同的子公司了，马云为什么要组织部？我觉得还有一个原因，成立三个子公司，是说公司把你们三个推出去，你们各自奔跑，用各自的能力，把三个公司带起来。
+
+但是呢，公司可以用组织部这样的方式，从虚的层面把大家框住，否则也许就变成三个完全分头奔跑的子公司了。这个就跟我党一样，各省去发展，中央不可能全管了，但是我还是有组织部，我也可以把人调来调去，这是一个道理，你可以把国家想象成一个大公司。
+
+无论是 VIPABC 还是途牛，公司都没大到这个程度，而且都还是围绕一个主体业务，没有必要用这种方式。
+
+极客时间：关于组织部你讲的这些我可以理解了。你也聊了特别多阿里让你受益的地方，如果让你说一个，在阿里工作这几年给你带来的最大的启发，或者触动是什么？你现在脑海里立马能想到的是什么？
+
+汤峥嵘：太多了，这个话题现在说说倒也是挺好的，你让我说最大启发，我想不到哪一件具体的事，或者具体某一条道理。但8年时间，阿里对我的影响是非常大的，把刚从美国回来的那个我改变了很多。我现在能做这么多事，我能够再去创业，靠的是阿里给我的财富。这笔财富不仅是经济上的，更多的是做人做事的方法、管理的理念、以及阿里校友这种近似血脉的关系。
+
+我刚刚讲，阿里的文化建设上绝对是让我做了 180 度转弯，后来从微医、途牛，到 VIPABC，我都认为阿里文化是最好的、阿里文化是无敌的，就是这种感觉，它改变我能到这个程度，因为确实事实证明了，这套文化能够把人的主观能动性给调动起来。
+
+另外，阿里的技术在这个整个互联网体系里面，我觉得是特别务实的。以前在硅谷做的技术方案是特别理想型的，要做就做最好的，创新成本很高。要说阿里有多少非常大的创新，不一定有，但我觉得在这个阶段恰恰是对的，要先活下去。务实就是说技术上计划好到底要投入多少。
+
+我曾经还负责给阿里采购一套电子邮件系统，我就按照硅谷的方式，做了几套方案，有免费的，有收费的，还有软硬件一体的，要老板批这个经费。我记得，最贵的可能都是几百万一套。老板会问我很多业务的问题，这个功能有什么用？为什么要花这么多钱，我给他讲技术上的考量，他就觉得没有什么意义，因为公司发展没到那个程度。在很多这种技术选型把控上，阿里更务实，现在来看，确实是对的，很多技术发展很快，当初选择一个技术觉得很好，付出很大代价，可能过几年就过时了。
+
+在阿里有这样的体悟后，我就知道在中国互联网创业公司，应该怎么去做技术了，我就不用老板再给我讲这些事了。甚至我作为 CTO，我会去压成本，就是我们能省就省，这个省不是说啥钱都不花，但是我自己知道，我是有能力让新技术在上面做叠加，但是没有必要为了一些面子在开始的时候把某个系统先做大，这对创业来讲就更重要了。
+
+还有就是，我在阿里毕竟工作了八年，这八年自己成长过程中，也有很多痛苦的时刻，但同时又看到成果，不断给我信心。我前面也讲到，我认为一个人往前走，你的信心是怎么来的很重要，我想就是因为我过去做成功的几件小事情，然后复用这个经验，或者凭借这些成功给我的信心，不断向前。
+
+你如果是个老司机，有十年都没出过车祸，出去开车你会觉得马路是很安全的，但是如果你昨天刚出了车祸，你就一定会觉得很不安全。客观上讲，这个世界只不过多了一起车祸，出车祸的概率几乎没有改变，但你自己的经历对你的影响，大到让你可以忽略掉所有的客观数据。
+
+所以我认为阿里给我最大的价值是让我积累了很多信心。
+
+极客时间：所以说，不断做成事，不断有成果奖励，对一个人的职业发展来说会有很大帮助？
+
+汤峥嵘：肯定是有，我觉得有时候你经历了一家好的公司，你感觉苗头还不错，你一定要多呆一段时间，因为它可能会持续给你带来发展。虽然可能这个公司很多事甚至都不是你做的，都是别的部门做的，你都会觉得跟你特相关，这些就会不停地影响你的人生。
+
+但是如果发现苗头不太好，不如及早离开，因为它对你影响即便不是当下，对你将来，也许就会有信心上的打击。
+
+极客时间：你曾经说在阿里最遗憾的事情就是，重构阿里国际站底层架构，原本计划半年时间搞定，但最后用了将近一年的时间，对业务影响非常大，还受过马云的批评。经过这件事，你才更深刻理解了“一边飞一边换发动机”的道理。你怎么应对这种“遗憾”的感觉？
+
+汤峥嵘：我的人生哲学是，对做过的事情没有什么值得遗憾的。因为遗憾这个词，还是有点悲观的意思在里面。我是觉得，既然发生了，就向前看。接受自己是一个特别重要的事情，觉得遗憾可能还是有点不够接受自己。
+
+遗憾分两种，一种是这件事做完之后，假如让我重来一次，我可能会换一种做法；一种是明明可以做到的事情，但开始就彻底放弃，那可能是一种真正的遗憾。
+
+但是呢，对当初重构国际站这个做法，我觉得我可以接受，因为我基本上尽力做了，我当时的能力水平也就是那个样子了，在管理上确实还不成熟，所以我就没什么好遗憾的，因为水平没达到。假如让我再回到那个时间点，如果我能力不改变，我当时肯定还会做那样的选择。
+
+互动时间
+
+聊一聊你所在企业有怎样的文化与价值观，你是否认同，对你有何影响？欢迎在评论区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/06怎样才能遇到自己的“贵人”？.md

@@ -0,0 +1,95 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            06 怎样才能遇到自己的“贵人”？
+                            极客时间：在成长过程中你有特别崇拜过谁吗？或者说心里有没有一个标杆式、榜样式的人物牵引着你？
+
+汤峥嵘：没有特别的一个人，我对大部分所谓“成功”的人都很敬佩，但没有特别的感觉。可能因为我是实干型的，我比较喜欢具体和我合作、对我产生影响的人，从他们身上学习东西。
+
+比如说我前面提到的关明生（Savio），他会把自己的亲身案例分享给我，手把手教我怎么做管理；在途牛的老板，他们很擅长捕捉市场的机会，让我在途牛学到了怎么快速试错、怎么融资、怎么创业；在 VIPABC，老板对教育和技术很有追求，让我学到了如何追求极致。这些可能是投射到我身上的，给我带来的财富。当然在今天这个时代有很多名人，他们做过的事，我都会看一看，但是我个人还是更喜欢看得见、摸得着的东西。
+
+我觉得从自身出发，我们要经常去跟在你身边的、比你水平高的人交流，你才有东西可学。通过实际的案例和数据，经过自己的算法，变成自己的东西，而不是看别人给你讲几句话就奉为圣经，你就觉得自己学会了。哪怕我们都非常喜欢乔布斯、马斯克、马云的名言，但我们看到的都已经是很久前，别人传了无数次的道理了，我觉得可能是被严重过滤过的东西。我不擅长处理这样的信息。
+
+像怎么解决 35 岁危机的问题，我觉得很难回答。如果你给我一个具体的人，说他需要帮忙，那我也许能帮得上。我可以跟他说，你现在的处境可以试试那个，试试这个，他去做了，且成了，这种才是真正的改变。但是要说这整个群体未来何去何从，怎么发展，我就是讲得再多，也改变不了什么。也许有这些困惑的人自己也有体会，听过很多道理，但还是改变不了自己。
+
+我们这些凡人真的就要靠周边的贵人来帮你了，不要期望看一本书、听一个故事、听一句话就能改变自己的人生，大家心里都明白，这是不现实的。
+
+极客时间：但是大家确实喜欢听这样的故事，或者说高人的建议，这也是为什么这样的内容、这样的问题一直会存在。
+
+汤峥嵘：当然，故事都很精彩，我自己也喜欢听，有时候看到某个视频讲这些也容易激动一下。但是过了一段时间，我就发现这个事已经忘掉了。还是得靠实在的人和事，我自己的路一直是这么走出来的。
+
+极客时间：几次提到关明生，你当时和他接触多吗？
+
+汤峥嵘：我在阿里时候不算多，反倒是离开阿里后接触很多。他是给我影响很大的人，他特别谦逊，而且很鼓励我。我刚去的时候，我的工资是比硅谷那边是降了一半的，但是比国内大部分人还是高很多，他就经常跟外面的人说，我们是把汤峥嵘给“骗”过来的，人家还降薪来支持我们什么的……他给我很多正面反馈来鼓励我。其实根本不是骗过来嘛，是我自己愿意回来的，但他给别人介绍的时候就会这样说。他这样做就给了我自信，给我很大的精神支撑。
+
+我记忆最深的一次，是我后来在 VIPABC，那会经常有一些对外部企业的分享，有一次一个银行的高端客户到我们公司来，结果没想到他就在里面。因为我们已经有好久没见了，我也不知道他在，那次就突然见到了。
+
+我那时候正好做 COO 了，他不是以前阿里的 COO 吗？我就跟他说我现在做 COO 了，他说太好了，我要教你怎么做 COO，给我讲很多。他就是特别喜欢培养人，把自己的东西教给别人，这点上他跟马云有点像，喜欢做老师。他做的每件事，很多细节都能让你折服的，确实非常难得的一个人。
+
+极客时间：从更具体的角度来说，吴炯和关明生，他们两位在哪些层面上对你会有影响？
+
+汤峥嵘：我认为每个人的人生中都需要有贵人相助的。因为每个人在一个阶段到达天花板的时候，就需要有人能带你看到上一层的风景，贵人就是把你拉到上面让你看一眼的人。我的贵人就是吴炯和关明生，他们两个人让我看到更高水平的人是怎么干的之后，后面就靠我自己的悟性了。后来我自己也有意识去帮别人一把，帮一些我之前带过的人。我看到他可能需要被拉一拉的时候，我就去拉他一把，至于他能不能接受，能不能悟到我的意思，就靠他本身的能力了。
+
+吴炯是两次把我带到下个阶段的人，第一次是他从硅谷把我带到阿里，第二次就是他把我从阿里拉出来，到了微医（挂号网）。而且第二次把我拉出来的时候，我就相信这可能是命运的安排，把我带进去，再把我带出来，不是挺好吗？
+
+而且我和吴炯当时在阿里并没有非常密切地沟通，他既然在这么长时间都没有找我了，他怎么就想到我了呢？肯定是有某种缘分又到了，那就再一起合作一下。去了挂号网，我跟Savio也接触更多了。
+
+所以，什么是贵人？天天在你身边的不一定是贵人。我认为贵人往往是，不知道哪天就神秘出现的一个人，然后给了你一个很大的帮助。我认为这个因果可能是在你不停的努力中慢慢积蓄的，绝对不是你想今天找到就能有的。
+
+你要发自内心的想“我就是想去跟别人学习”，而且你对人家是没有期望的，如果你是这个类型的人，贵人跟你就有缘。反过来想，很容易明白的道理，假设你去帮另外一个人，你肯定不想帮那个特别想从你身上获取的人。而当你发现有个小朋友很厉害，老想向你学习，但是从来也没管你要过啥，可能经常还给你送东西，那你对他就容易有好感，有好事就会想到他，我觉得道理是一样的。
+
+所以，首先开启自己想学习的心态，但别人是不是收你为徒，真的是靠缘分，靠运气，而且靠你自己的努力。你做得多了，高僧自然会收你为徒弟。
+
+随着工作年龄增长，所有人都会发现，我们自己是非常渺小的，全靠我们自己努力还是比较难的，往往要靠外力相助才能走得更远。也许你这辈子就自己奋斗，也很好。也许你运气好，就能往上跳一层。有的人天生就是富二代，含着金钥匙出生的，他就应该去做更好的事情，也应该做更大的事情。这个世界肯定是不公平的，这个世界一定不是把所有的资源公平分给每个人的，我们必须得接受这一点。
+
+我们在宇宙中本就是一个尘埃，从这个角度想，接受自己的渺小，这个时候你就是无所谓的，当你看到别人很厉害，那有机会就去学习就好了。
+
+极客时间：你会有意识地向这样优秀的人靠近吗？
+
+汤峥嵘：肯定是喜欢跟优秀的人在一起，物以类聚，人以群分，要想成为优秀的人，就得跟优秀的人在一起。和优秀的人在一起，其实是有压力的。特别是他们指出你身上缺点的时候。相比起来，刷刷成功人士的心灵鸡汤，似乎感觉好很多。所以成长一定是有痛苦和代价的。但是当你被比你优秀的人接受以后，你就知道自己离优秀又近了一点点，你的信心也多了一点点。
+
+极客时间：成长过程中，很多人讲要顺势而为，要知道大势，跟风而动，看重环境对自己的影响。有个现象虽然老生常谈，还是想聊一下，就是大家都想进大厂这件事，国内特别明显，都想去大公司，大公司意味着更有前景的业务，更牛的人。这确实是一个刚性需求。你觉得大家在规划职业路径的时候，应该先去大公司，还是说在小公司会更好，总之要有一种成长的方法。
+
+汤峥嵘：我可以说说我的看法，这个点是因人而异的，回到性格上，像我这样性格的人，可能恰恰适合先在小公司，再去大公司，为什么？因为小公司能够让我发挥更大的价值，让我更有自信。
+
+大公司可能周边人都很强，你在大公司里分割那么一点小事情，做得可能更加机械。但是如果你这个人是特别善于捕捉外部的信息，从性格上讲，比如说你是一个直觉型的人、外向型的人，你可能去大公司之后，很早就感知到大方向了，你就能给自己规划好未来，那这样的情况去大公司更好。
+
+这跟创业本质一样，有的人很容易感知到未来的变化，而像我这样的呢，都是完全靠自己经验跑出来的，反而在小公司积累的那些信心对我影响更大。而且，还是我前面讲过的，公司是一个很多人组成的平台，我还是更看重公司里的某个人对我的影响，举个反例，假如你去到心仪的大公司了，但是你碰到一个很差的老板怎么办呢？可能因为他的影响，你的自信心一下就被打击到了。所以确实有太多不确定性在里面，不能把复杂问题简单地黑白化。
+
+归根结底，还是要了解自己，你自己是什么样的人，喜欢什么样的环境，在去大公司或者小公司之前，把公司情况、团队情况、你自己的情况统统考虑进去，再做选择，而不是盲目地认为公司大小对个人就有决定性影响，还是要关注具体的人。
+
+极客时间：嗯，这个可以理解，比如在小公司，你已经是技术最厉害的人了，而且你的自驱力很强，你自己就可以让自己一直往前走。但对于很多人来说，他可能需要一个师傅或者领导带着他往前走，这可能是两种完全不同的人，不同的状态？
+
+汤峥嵘：有人能带你，教你一些东西，这是运气，但还是要靠你自己的努力，才能遇到我们讲所谓的“贵人”。你说的这种需要师傅来牵着走的呢，我认为他就是把自己框住了，自己没有努力过。现在很流行选择大于努力的理论，但我更相信努力。因为只有努力是自己可以控制的，选择、机遇、贵人、天分等都是自己无法控制的。
+
+我在第一家公司工作的时候，我不是技术最厉害的人，我只是最钻牛角尖的那个人。技术牛人也大有人在，只是说那时候大家的技术平均水平没那么强。
+
+那家公司的老板后来招了一个天才进来，真的是个天才，非常厉害，因为他太厉害了，什么都不干，我就在那苦干，遇到不会的东西就去找他，他都能给我解答。包括 Java 刚出来的时候，他自己不写程序，但是很快就把 Java 核心搞清楚了，那是真正的天才。
+
+但是他后来发展很一般，公司淘汰人的时候他也被裁掉了。我是很多年之后跟他有联系，我发现他也没有变得所谓的“成功”。我很震惊，因为他的智商绝对是百万分之一的那种，可以轻易碾轧绝大多数人。
+
+认识到世界上确实有这么高智商的人，而且他在你身边工作过，就越让我感到，我们这些凡人就得靠努力，没别的办法。刚刚说到要靠别人推着走的人，你又想要好东西，你得想想凭什么呀？你是真的没有能力吗，还是自己没努力过就觉得不行？技术人大部分的工作，都是脑力劳动，你要是说，因为脑子的问题自己做不了，那就没办法了。你要觉得自己不是脑子不行，做不好的原因无非就是没别人熟练，那就多练嘛。
+
+别人有 20 年工作经验，和你没有工作经验的比当然比你厉害了，但是你想要，当你有 20 年工作经历的时候，要做到比他厉害，这其中怎么努力就是你自己的事了，不管是多付出时间还是怎样，我认为没有什么不可以去做的事，不要自己把自己先框住了。
+
+极客时间：今天，成功这个概念是被高度狭隘化了，拥有财富、权利、地位的人往往被叫做成功人士。我觉得你其实也在表达，自己努力，同时拥有好运气，才达到成功。我也想探讨，一个普通人怎么才能不断靠近自己心目中的成功呢？除了上面谈到的关于个人努力、和水平高的人交流、向优秀的人靠近，在做选择前充分了解自己之外，你还有什么感悟和切身体会么？
+
+汤峥嵘：我不觉得自己有资格去回答如何成功这类的话题，甚至都没有资格去定义什么是成功。但是我可以分享一下我对人生的一些观点。
+
+在信息技术高度发达的时代，我们被少数所谓成功的人搞得很焦虑。我们觉得自己很客观，但其实我们被焦虑的情绪控制着，我们很主观。简单地做个数学计算。今天地球上有70亿人，而我们每个人知道的成功人士应该不超过7000人吧。那么成功的概率最多也就是百万分之一。这和中彩票也不相上下吧。其实绝大部分人都是和我们一样平庸的人。买彩票不中肯定是可以接受的吧，那么同理，平庸也是完全可以接受的啊。
+
+我前面讲过，其实情绪本来的作用是让我们逃避危险，让我们生存。适者生存，才是大自然的普遍规律。能存在，本身就是一件很了不起的事情了。我这里不是让大家变得佛系，放弃努力。而是不要被情绪绑架。试想你是一只龙虾，在龙虾的世界里，你靠不断地战斗获取了同类的认同，成为了龙虾中的王。而在人类眼中，那又怎么样呢，你不过是一只龙虾而已？更不要说在大自然这个造物主眼中你是什么了。情绪不过是大自然赋予龙虾的一种生存能力而已。我们现代人既然没有了生存的危险，就尽量放下情绪，放下焦虑。当然这个不容易做到。我的解决办法是我最擅长的领域：数据。
+
+其实我是有轻度焦虑症的。我几乎每天都在用我们的产品测量自己的情绪，我在睡觉的时候要比绝大部分人紧张焦虑。但是当我知道自己的这个问题，并且可以量化以后，我反而觉得不那么焦虑了。因为焦虑的底层逻辑是对不确定性和风险的担心。我通过数据对问题的定位比过去清晰了很多，也就意味着解决的方案也清晰了很多。我在用各种方法减轻自己的焦虑。我们已经把一些有效的方法结合到了我们的产品中了。
+
+当我们接受了自己的平庸，了解了自己的情绪和性格之后，我还是鼓励大家积极向上。这就回到了之前提到的两个我的价值观，“过度努力”和“独立承担责任”。过度努力的核心是积极争取，不计较得失，也不让自己后悔。独立承担责任的核心是接受任何后果，不把期望值放到其他人身上。我认为把这些我们能控制的事情都做了，那么就看运气了。运气好的话或许会中彩票，但大部分时候不会，那也再正常不过了。
+
+互动时间
+
+在职业成长过程中，你有遇到过自己的“贵人”吗？他曾经对你产生怎样的影响？欢迎在评论区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/07选行业秘诀：技术是否能发挥重要作用？.md

@@ -0,0 +1,121 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            07 选行业秘诀：技术是否能发挥重要作用？
+                            编者按：从阿里到微医、途牛、VIPABC，再到创业，汤峥嵘每次的选择都是积极向前看，离开一个地方到下一个地方是因为有了更好的机会，他永远希望选择更好的机会。每一次换公司，即便行业有所不同，他都遵循一条主线，那就是：业务能否因为技术的影响而产生显著的变革，如果技术能发挥重要作用，那么个人投入就有价值。
+
+这一节，我们主要探究技术人在选择变换行业的时候，应该关注哪些方面的信息。以下为访谈对话。
+
+每一次选择，都向更好的机会看齐
+
+极客时间：在阿里待了 8 年，离开的时候，有没有自己对这段经历做总结？后来到微医、途牛、VIPABC，再到创业，每次决定要换一家新公司的时候，而且这些基本上都是不同行业，你都是怎么去做选择的？
+
+汤峥嵘：我其实很少因为所谓的要对过去做个总结了，就要反思自己。我比较实用主义，我总结的目的还是希望接下来能用上，比如工作中需要，我就总结一下过去有没有可以借用的经验，这样印象是最深的，否则就变成一个形式上的总结，给自己一个所谓的交代。比如说这次你们希望我能聊一下过去，才“逼迫”我有一个机会去总结一下，否则我平时自己空下来挺少去琢磨这个东西的。
+
+在阿里8年后离开，那个时候我没有特别明显的遗憾的感觉，可能是因为我要去的这家公司（微医），又是阿里的两个 O（前 CTO 吴炯、前 COO 关明生）在里面做重要角色的，我也没有觉得那是一个特别大的改变，后来阿里几位离职的同事来和我一起干，我们仍然还在阿里的这个光环下在做事。
+
+至于离开去下一个地方，有人可能觉得说，因为对上一家公司不满，就找更好的机会。本质上找更好的机会是对的，但不是因为我不满。我绝大部分过去的选择都不是因为对前面的企业不满意，而是说在比较两个机会的时候，下一个机会我认为明显可以给我更大的提升，那我就选择去下一个地方了。我的人生观还是积极向前看。
+
+极客时间：因为你在微医时间很短，一年就离开了，事后分析，是不是觉得当初并不是一个正确的决策？
+
+汤峥嵘：不能叫不正确的决策，而是说当时在微医很多想做的事情，都没有条件，我们做得太早了。我觉得，我们当时想做的事情，如果搬到今天可能就有条件了，我认为是这样的。所以我为什么选择离开，也是这个道理。
+
+从我们做互联网的产品和技术角度，那个时候很多条件都不成熟，比如说你没有大数据去算很多东西。你也没有好的的穿戴设备获取患者的健康数据，当时主要的一个产品就是挂号网，就是帮大家去挂个号，一个过于简单的模式。
+
+从公司老板、业务团队的角度看，还是有很多可以做的，比如整合医疗资源之类的。但是我从技术角度没看到能发挥什么更大的作用。我之前采访中也讲过，我做选择，换公司，我有一条主线，我认为这个公司做的业务，或者是这个领域在这段时间内，能通过技术进行比较大的变革，我觉得投入就有价值。
+
+我刚加入的时候是觉得，我们能把挂号这个业务做起来就很好，因为那时候心中觉得，这件事是个好事，能让大家足不出户就挂到号。但是业务推出去之后发现不对的地方了，稀缺的专家号一上线就被秒杀，被黄牛抢走，导致那些真正需要的人反而挂不上号了，因为我们做的挂号当中，主要的特色是能在三甲医院挂号，中国人就是缺的号就是三甲医院的专家号，别的号也不缺。我当时就觉得这有点事与愿违。
+
+经过这段经历，我也就总结出一个道理，互联网应该是解决长尾资源的问题，假如这个资源多出来了，互联网可以帮你卖掉，但是如果本身就是个稀缺资源，就不适合放在互联网上，互联网恰恰是要卖那些不太好卖的东西。
+
+我当时就看不出来，如果再往下走的话，我们这个技术，到底能对这个行业产生多大的变革了。后来也做了很多事情，无非就是把线下医院打通，都是很普通的一些技术，甚至去找个外包团队就直接把它干了。从技术上讲，因为整个医疗体系的技术是非常落后了，这个事情就变成把落后的医疗体系稍微往前赶一赶，就行了，我觉得这就完全不是我想象的，能够靠技术让行业产生变革。
+
+而无论是途牛，还是 VIPABC，技术对商业的变革都产生了很大作用。虽然它不是决定性的，但是没有这些新的技术，这些商业肯定做不起来。当时微医是不具备这样的条件，也不能怪微医，也不能怪我，就是我们都试过了，尝试完了之后发现不成熟，那我就换一换。
+
+我的性格上是这样，我是有意回避一些我认为悲观的东西，我觉得当你看到太多负面东西，或多或少就会在你脑海里沉淀下来，对你做判断会有影响。
+
+极客时间：可以说一些细节吗，你会回避一些不太好的东西，无论是生活还是工作中，怎么回避负面信息？
+
+汤峥嵘：所有东西都可能有不好的一面，举个例子，在微医刚刚接触医疗，可能会质疑，中国医疗体系怎么这么差？值不值得再去把它给改变一下？确实我们跟国外差得还是蛮远的。
+
+我们那时候得到医生给我们反馈的数据，从医生角度来讲，有 70%的误诊率。什么意思呢？就是这个病人本不应该是给他看的，但是挂到他那去了，来了 10 个病人，只有 3 个病人是应该给他看的，为什么？因为中国挂号体系是开放式的，哪怕很小的病，一个普通医生就能看，但大家也想挂最牛的专家，但对那个最牛的专家来说，可能就是浪费了他的资源，他本来可以看很多疑难杂症。到今天为止，还是这样，你要从负面去看，很悲观。但是从正面看，改进的空间不是很大吗？但凡我往前推进了一点，不是就赚了呀。
+
+我相信所有的问题都有解决方案，所以当你看到的问题越多，那就说明你的机会越多。对纯技术人来说，你就是要去解决公司里最难的问题，这就是你的捷径，你就会成为大家心目中的专家，就像阿里的多隆，最后就变成“神”了。
+
+一旦你真的解决了几个问题，打出了名声，“疑难杂症”就会主动找你来了，而比较平庸的人都没这个机会。最牛的专家，根本不缺用户，不缺流量，普通人可能没有机会解决难题，牛人天天都在解决难题。所以，为什么我说要乐观？给我们问题，就是在给我们机会。
+
+极客时间：你刚刚讲到互联网应该解决长尾资源的问题，可以再解释一下这个长尾理论吗？
+
+汤峥嵘：长尾理论最先提出来是用于描述像亚马逊、Netflix 的经济模式的（美国《连线》杂志主编在 2004 年提出，主要观点为：如果把足够多非热门产品组合到一起，实际上就可以形成一个堪与热门市场匹配的大市场）。
+
+
+
+拿亚马逊举例，以前在实体书店，极少数的书籍成为畅销书，书店营销就以畅销书为中心，越畅销的越摆在靠门口的地方。但是还有更多书“藏”在书店的深处，可能没人看，销量甚至为 0。畅销书虽占很小一部分，却产生巨大经济效益，但如果能把非畅销书的长尾销售额都加起来，也许可以超过头部的经济效益。这就是互联网能带来的好处，这些电商公司也都能赚到钱了。
+
+但是挂号这个业务不一样，某个时间段，一个医院一共可能才那么多号。原来大家排队，可能周围几十、几百公里的人来抢，你现在放到网上，全中国的人不就都来了吗？瞬间就抢没了。后来我做教育也遇到同样的问题，好的老师就会变成稀缺资源，如果让大家抢，一定都抢最好的老师，这就会导致很多客户都不满意：怎么我就没抢到金牌的老师？所以，具体业务具体分析，到底需要解决什么样的问题？有的问题就不太适合用互联网解决。
+
+技术驱动业务，经验与教训
+
+极客时间：刚刚你聊了自己做选择时遵循的原则，一个是向更好的机会看齐，另外一方面，就是看技术到底能发挥多大的作用。你也说过在途牛和VIPABC技术是发挥了重大作用的，因此想聊一聊怎么才算技术发挥了重要作用。先从公司业务发展角度看，你觉得应该是技术驱动业务，还是业务来拉动技术？
+
+汤峥嵘：我先说结论，我认为有些技术本身可能就会把业务给颠覆了，都不是驱动，一定会有。但是你在没想好业务模式的情况下，就去期待所谓“颠覆”，这是不太现实的。途牛和 VIPABC 会比较典型，特别是 VIPABC，我们是有点想走技术驱动业务的这个模型的。
+
+我觉得这个话题很有意思，技术人员比较容易陷入到一个自我畅想和狂欢中，都希望造出一个“原子弹”（颠覆性技术），然后就变成业务之王。但是我认为这个不太可能，你做技术的还得听业务的需求，但是牛人可能就会在做业务需求的时候，发现技术颠覆性的苗头了，这个时候就可以跳出来说，我本来是为这个需求去做的，但是我打算拿这个技术干别的去了，这个是有可能的。
+
+像国外的很多公司就是这么干的，很多我们认为并不是一开始就想好的，比如说，我看最近很多视频都在讲乔布斯 15 年前发明了 iPhone。你说乔布斯当时能想象出今天的 iPhone 影响有这么大么？他当时就觉得 iPhone 就是一个超级牛的iPod音乐播放器，加一个超级牛的电话，加个一个手机上就可以打开的浏览器，这三者的组合，对那个时代来说，这已经非常颠覆了，但是没想到今天的手机已经远远不止这三样了。我是觉得连他这样级别的人创造出这么牛的技术，他在当时的场景下也还是为了业务。
+
+极客时间：你说过途牛和 VIPABC 技术驱动业务比较典型，途牛的业务，是怎么体现技术驱动的？
+
+汤峥嵘：从技术的角度来讲，我认为途牛这段经历中，技术是对商业产生影响的。
+
+首先，我们有自己本身业务的创新，另外，当时行业内几家竞争公司包括携程、去哪儿都在做技术创新，大家互相比拼着、共同做出来的一些技术，一定程度上改变了旅游业的形态。
+
+途牛本身的创新来自于跟团游放到线上去做，之前大家认为跟团都是线下的、非标准化的产品。在途牛我们当初的想法就是，能不能把这种非标准化的东西拆开来，做到可以对比。但因为出发、回程的时间不一样、机票价格不一样，去的景点也不一样，这是非常复杂的，也很难比对。那就算不可比，我们能不能把里面的组合透明出来，供用户选择呢？所以我们又开始拆，比如你去旅游一次，肯定含交通、酒店、旅游景点门票，假设还有个导游。
+
+当时，我们做了很多欧洲游，因为欧洲非常规范。就拿导游费这一项来说，可以做到透明。
+
+因为你知道在那段时间，线下旅行社很多都已经被做烂了，特别在国内，打着不花钱的噱头，甚至还有说跟着去旅游一趟，他给你 50 块钱。但等你上了车，就拉着你去购物了，这些导游是靠购物来返点，你不购物他就不高兴，就不给你好好导，你就很难受。
+
+我做了途牛之后，我更深入去了解整个链条，都变成什么样呢？相当于旅行团先找导游，说我现在有个团 40 人，导游你要不要？要的话，导游要先付旅行社钱，旅行社才把这些客户给你，这等于客户变成流量了。比如说导游一个人付两百块钱，他总得在每个游客身上赚回来两百吧，所以就得带你去购物，才能返点。碰到死活不买东西的，当然导游拿他也没办法，但是态度就会比较差嘛，这就是一个非常恶性循环的过程。
+
+后来，我们做跟团，尽可能都是做这种“0 购物团”。像欧洲呢，第一，他们有一个导游协会来管这些导游；第二，你去欧洲所有地方购物，价格都是一样的，它们会记录是哪个导游带人，游客都花了多少钱，所以欧洲整个旅游系统就非常好，旅游体系比较健康。
+
+欧洲游我们当时就是这么拆的，加了个导游费用，因为游欧洲确实需要导游，玩一圈经常跨几个国家，多国家语言。欧洲很多有特色的教堂建筑，确实需要导游给你介绍，这样就把整个旅游当中，所有该花钱的点都拆好。
+
+做到透明了，接下来我们就开始做组合了。我们研究了很多跟团的数据之后，就抽象出大家比较喜欢的路线，我们就把这个路线规划出来，做一个标准化的产品。比如法瑞意三国七日游，很多人走过了，我们也做一个这样的路线，在线上售卖。如果你想做个性化调整，比如你不想住我规划的酒店，你可以换，没有问题，我们用技术支持个性化调整，这样的模式呢，我们就叫他自由行，但它核心原理还是参考跟团的路线模式。
+
+要做到这些，显然是跟我们的计算能力各方面有非常大关系的。因为我们实际上是预先把所有的价格信息全部都获取到，放到我们数据库里面，每天争取更新多次。很多人都是 1 月份的时候想安排 6 月份出行，他得知道那时候酒店是什么价格，我们就做数据处理，按价格排序，哪天最便宜，都给算出来，这需要非常大的算力。
+
+我们专门设立了一个价格中心，让非常优秀的人去做这个事情。从技术上讲，这就是推动业务发展的，相当于支撑了一种新的商业模式。
+
+除了个性化的自由行，再反过来说，大部分人愿意牺牲个性化选择，可以跟团。以前跟团的做法都叫做：出发地成团。比如你在北京组的团要去欧洲玩，就是北京这边找几十个人，一起从北京出发。一般是40人左右，正好坐一个大巴的容量，好管理。但即使是北京这样的大城市，能在同一天或同一周去欧洲相同目的地旅游的人并不算多。于是旅行社只能每周发1个到2个团。而且有不成团的风险。当我们仔细研究的时候，发现国内的旅行社其实只负责提供从北京到欧洲这段的往返机票，甚至有些时候连机票都不负责。到了欧洲之后，完全由当地的地接社提供导游、酒店、门票等服务。
+
+途牛就发明了一个新的模式，叫目的地成团。就是大家可以从全国各地出发，然后到了欧洲某个城市后，再组团。这样大大提升了成团的概率，因为全中国想要同一天去欧洲同一个目的地旅游的用户很容易超过40人。于是我们直接跟国外地接社谈，不仅保证每周有多个团，甚至每天有多个团。地接社当然愿意，而且因为量大，给我们更优惠的价格。我们只需要把从国内大城市出发到欧洲的往返机票给配上就行了。对于用户而言，可选择的日期一下子多起来了，几乎每天都有去欧洲的跟团游，而且价格还比以前便宜。
+
+这个就是技术改变商业模式的案例。途牛当时做得非常不错，推动了旅游行业的变革和旅行方式的改变。
+
+极客时间：VIPABC 的技术壁垒是什么？技术对教育的改变体现在哪里？
+
+汤峥嵘：我在 VIPABC 的时候，有一件事是站在他们的肩膀上，就是他们本身有一套课程的匹配算法叫DCGS（Dynamic Course Generation System，动态课程生成系统）。VIPABC 在当时教育行业里是第一个做匹配算法的，其他做教育的公司都没有。我们那时候是整个行业唯一一家，能够动态地把这么多学生、老师、课件都智能匹配的公司。匹配算法它创建了一个什么理念呢？打破无论是在线下教育还是线上教育中，学生选老师的模式。
+
+之前的线下教育的选课模式是，先把不同老师的时间表公布出来，贴在墙上，供学生去挑选。因为在同一个校区或培训班中，老师的数量和上课的时间都是非常有限的，学生往往不会有选择焦虑。这个模式在线下完全没有问题。
+
+但是当这个模式被搬到线上以后呢？因为互联网打破了时间和空间的限制，让老师的数量和可以上课的时间段大大增加，大到你可以认为是无限大。选择多了反而会成为焦虑。因为大部分人总想选好的。那么平台上很快就会冒出所谓的“好”老师和“好”时间段。而这些所谓“好”的资源永远是有限的，就跟挂号都挂专家号一样，“好”资源很快就不够了。当时好几家在线教育机构采用了用户自选老师的模式，导致用户抱怨总是抢不到“好”老师。
+
+VIPABC发现在英语培训和其它素质类教育中，所谓的“好”，其实非常因人而异。比如对于初级学英语的人，名牌大学的英语系教授未必就好，甚至是浪费资源。对于一个想练习口语的人，一个富有感染力的人能让你自信，多开口，进步快。当我们做用户调研时，报告显示，白人和英美口音的老师最受喜爱。但实际的客户打分却不是这样，反而是黑人老师和东欧老师的打分最高。分析下来，因为黑人老师和东欧老师的肢体语言和表情都非常丰富，对提升上课效果有非常大的帮助。
+
+所以VIPABC的课程系统，不允许学生选老师，但是允许你选任何时间上课。我们根据你的上课时间，我给你匹配最合适的老师。另外，我们还有给老师打分的体系，有了“老师喜爱度”这个维度的数据，后面在匹配课程的时候就越来越准了，满意度也会越来越高。
+
+更有意思的是，早期我加入 VIPABC 的时候，还是以一对多形式为主的，一对一还没有开始流行。一对多的时候，我们连学生的组合也是攒出来的。我们把老师、学生和这节课要上的内容都动态匹配出来。
+
+这又是一个技术改变商业模式的案例。虽然由于资本的大量涌入导致整个行业的非理性甚至坍塌，但我相信这个技术理念是对的。教育就是应该因人而异，给每个人一个适合的发展路径，而不是所有人都去追求少数“好”的路径。希望当教育行业回归到理性后，这样的技术可以再次冒出来推动社会的进步。
+
+互动时间
+
+你所在公司的技术团队做的事情，对业务或所在行业发挥着哪些作用呢，可以说说你的理解和看法么？欢迎在评论区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/08途牛野蛮生长，也促使CTO“野蛮生长”.md

@@ -0,0 +1,79 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            08 途牛野蛮生长，也促使CTO“野蛮生长”
+                            编者按：汤峥嵘2013年加入途牛，正值移动互联网浪潮，途牛乘风飞速发展，2014年就在美国上市了。2016年汤峥嵘离开途牛的时候，技术团队已经从刚来时的 200 人，扩张到了 1500 人。在途牛，这位CTO养成了一个更好的习惯，那就是深度参与业务，同时正是这段经历，让他真正知道了创业应该怎么做。途牛的野蛮生长，促使汤峥嵘进行了一场蜕变。
+
+极客时间：感觉途牛应该对你改变挺大的，因为这是一家创业公司嘛，你又以非常核心的角色参与进去，应该比在阿里这个体系中要承担更多的职责。
+
+汤峥嵘：确实，在阿里我并没有像途牛这样，参与到比较重要的角色当中去。而且阿里体量是比较大的，途牛相对来说还是体量小，我作为 CTO，对公司影响也比较大，而且途牛那个阶段又是几家（去哪儿、携程等）竞争非常激烈，高速增长的阶段，确实给我很大发挥空间。
+
+而且对我来说，我当时去途牛还有一个很重要的原因，因为阿里也好，微医也好，创业团队都是 60 后、70 后主导，而我在加入途牛的时候，途牛这两个创始人他们才三十出头，很年轻。我那个时候认为未来是 80 后主导的，我就想要去体验跟 80 后创业是什么感觉。果然，到了途牛我就发现，面对不确定性的时候，80 后更具有快速尝试、快速迭代的风格和勇气。
+
+70 后相对来说，还是愿意先定战略，再定规划，分析清楚后，最后再去做。80 后给我感觉很不一样，我前面也讲，那个喜欢天天出去外面看的创始人严海峰，他看到什么新的东西出来，就回来跟我们讲，快速分析一下，我们觉得 OK，就去做了，就是这样。
+
+我认为我很幸运，因为我能感受到我们做出来的东西能产生商业价值，因为它确实改变了原来旅游业的商业模式。当然我觉得能成功还是因为，商业上有这样的需求，从技术角度我发现我们居然能做到动态打包成一个线路，那后面再做目的地成团什么的，自然就会有商业价值了。
+
+那个时候，整个行业越往后做，越发现互联网对这些标准化的旅游产品，比如说机票、门票这些生意有很多影响，确实改变了行业。
+
+比如说机票，过去都是旅行社卖机票，它的返点是非常高的，卖出一张，给一个返点，甚至有前返、后返等各种激励政策。比如旅行社卖给客户一千块钱一张机票，可能拿到一百块钱的返点。互联网公司一进来之后，想办法把这钱给到用户，然后各种各样的打折就跑出来了。于是各大航空公司就很不开心了，因为他们觉得互联网公司损害了他们的利益。到今天，你会发现，在任何旅行社、网站上定机票，跟航空公司官网定的价格是一模一样的。现在这些航空公司已经不给任何返点了。这也是为什么很多订票网站会不停地加各种保险让大家去选，因为没有别的赚钱方式了。
+
+但是我认为整个行业是进步了的，因为消费者享受到了实实在在的好处。我觉得那段时间，途牛包括去哪儿、携程这几家一起做，确实改变了旅游行业，像去哪儿的技术是非常强的，它的搜索是做得最好的，途牛有些部分跟它做得非常相似，我们在此基础上再做创新，做组合比价。
+
+极客时间：刚才你聊到，你觉得 70 后和 80 后 CEO 在管理上有些区别，在定战略，做规划上。你会觉得途牛这个方式就是好的吗，还是容易踩坑的？
+
+汤峥嵘：我是觉得没法说谁对谁错，谁好谁坏，我当时就感觉在这样“小步快跑”的方式下，途牛的发展速度是非常快的。
+
+因为在那个时候，做在线旅游的这几家就是一团混战，必须分秒必争的。我 2013 年过去的时候还是网站模式，到 2014、2015 年的时候，就已经是移动互联网的风口了，我们也是相对比较早切到 App，抓住 App 这个流量红利的，专门分出了一个做移动的团队。我记得途牛 App 的增长速度真的是指数级增长，非常快，很快 App 上的交易额就超过了网站，这是我那时候明显感觉到的。
+
+我觉得 80 后对移动互联网的崛起是天生的敏感，知道怎么做，而70 后从Web1.0到Web2.0，从PC到移动是需要时间的。这个差别我是觉得挺有意思的。
+
+极客时间：你在之前的采访中也有说过，你选择加入一个团队，你会看自己和这个团队的人价值观是不是相符，气质是不是相投，具体是怎么去判断这个事情？
+
+汤峥嵘：还是要靠聊，靠沟通，比如说途牛的两个创始人，他们是很有诚意到杭州来找我聊的，当时我并不知道这个公司是什么样子，途牛其实那个时候还比较小，我就说可以跟他们聊聊。
+
+第一，我知道他们俩是 80 后。第二，我发现他们俩人非常正直，因为他俩一个是大学毕业一年开始创业的，一个是相当于在大学期间直接就开始做途牛，都是没有在大公司里面工作过的，没有经历过很复杂的企业文化，我觉得他们就是非常的单纯、充满理想。这点我就比较看重，我也是比较简单的性格，通过接触我感觉跟我特别契合，这是让我加入途牛一个很主要的原因。
+
+极客时间：我不知道这算不算偏见，像你作为 CTO 这样的级别在找团队的时候，应该更有话语权，但是比如像刚毕业的大学生，或者是工作经验不够多的时候，他怎么去找到和自己价值观相符的团队，这个会不会更难？
+
+汤峥嵘：我觉得是这样。还很年轻的朋友，可能还不清楚自己是什么样的人，对价值观这件事情本身就了解得不多。首先要搞明白你自己是什么样的价值观，才能做选择。
+
+我是觉得做技术的人应该都比较单纯一些，不善于绕弯子。我个人认为，未来想长期在技术领域去做的人，就应该去找看起来比较正直的老板，这样我们就可以全心投入在技术领域。你在选择团队的时候，选择老板的时候就不要去选择看起来城府很深的人。我最怕城府深的人，我觉得大部分技术人也是这样的，我是什么事都写在脸上，别人能把我看得很清楚，但如果我看不清楚对方，我就觉得心里有点虚，因为你不知道他到底心里是怎么想你的。
+
+但和人沟通也是一项重要技能，这种感觉也需要练出来，因为你想，要让简单的人去能够看懂复杂的人，这个事情肯定是有点悖论，我们就得靠练。所以对于刚毕业的同学你先搞清楚自己能接受什么，不能接受什么，锻炼和别人交流的能力，保持真诚，是不是合拍大概率是能感受出来的。
+
+极客时间：你去的时候途牛技术团队有多少人？你在途牛遇到的比较大的挑战和困难是什么？
+
+汤峥嵘：到了途牛之后，我的核心任务就两个，一个是能够理解老板要做什么事情，甚至能够站在他的角度去思考，另一个就是要快速组建团队。
+
+2013 年、2014 年整体形势都非常好，我 13 年加入途牛，14 年我们就去美国上市了，走势非常快。我觉得我运气特别好，我进去的时候，途牛就开始有一个往上的拐点。你看我去的时候技术团队大概两百人，到我 2016 年走的时候，技术团队已经 1500 人了。
+
+遇到的比较大的挑战就是，怎么能够找到这么多优秀的人，并且能在队伍快速增长的时候保持好队形。另一个挑战是用什么样的技术架构和管理架构去承接快速增长的业务。压力更多来自这些方面。
+
+我们有很多技术也是靠这些优秀的同学去做，比如说怎么能动态算价格啊，就是价格中心这个技术团队做的，价格中心依赖的是，你要能够去快速找到价格，有些是我们通过别人的 API 来提供价格，有些就直接爬取公开信息。因此搜索和数据非常重要。当时的搜索团队和大数据团队几乎是从零开始搭建的。我们很快做了一套非常好的搜索系统和大数据中心。非常实时地提供各种维度的报表，辅助决策。在爬虫、搜索技术、还有大数据上，我们技术团队还是非常强的。
+
+极客时间：从200人到1500人，你管理的带宽也会比之前大很多，这么大的团队，当时在管理上感觉吃力吗？有什么经验分享么？
+
+汤峥嵘：还好，没有觉得很吃力，我对这个团队管理还是花了很多精力的，这些兄弟们跟我关系都一直特别好。我认为，我的责任不仅仅是一个 CTO，我要把这些人都带起来，让他们成为发动机，他们只要能力强了，他们成为每个部门的 CTO 了，我就轻松了，我的秘方就是这个，要不然我肯定会累死。我花了蛮多时间，跟他们做各种沟通的。
+
+在管理上，我感受到阿里带给我的一些好处，特别是技术体系这块，我率先把阿里的技术层级体系（指阿里 P 序列）引入到途牛技术部，后来这套体系才推广到全公司的。当时动员了公司各个部门，一起来研究针对我们公司的层级应该怎么定义，不完全按照阿里的标准。为了做这个事，我还设置技术委员会，有点像阿里的组织部，让公司里比较优秀的干部、优秀的架构师，都是技术比较强的人加入进来，由他们来主要决定技术层级应该怎么定，相当于把这个职责就给到他们了，他们也会觉得自己很有价值和意义，会用心做这个事情。
+
+同时呢，因为越往上晋升越难，大家肯定也遇到过吵架的情况：“这个人为什么能升，另一个人不能升？”还有比如说，这个人他在公司人缘好，认识的人多，而且做的事情委员会的人都了解，可能在晋升的时候就会占便宜，另一个人和技术委员会的人不熟，只用一个小时的汇报时间说服评委，总是有点难度。
+
+我说我鼓励你们平时就去影响这些技术委员会的人，但凡有评审，就一定有人的因素在里面，你们不要把技术委员会想象成完全公平的。我说你要是有能力把他们买通都没关系，因为我相信这些技术人他们心里还是有一杆秤的，主要还是靠你做的东西好不好来评判。但我鼓励他们多表现，这种表现也是有正面影响的，因为太多技术人可能技术很强，但是不太善于表达，就容易吃亏。我也跟他们的领导说，你的责任之一就是要把你下面技术很牛的人，介绍给别人，要不然他上不去是你的责任。
+
+当时在途牛，有这么一个大好的环境给了我，让我做这个事，我对这段经历，还是非常感恩的。因为整个业务在高速增长，老板也很善于把控方向，反过来给了我们技术发展的空间。因为严格意义上讲，这件事情本身为公司创造不了什么直接价值，你必须得有足够好的业务，赢得老板的信任之后，你才有空间去做这个事情。
+
+极客时间：你有没有去复盘过那三年，对你未来发展的影响，那三年应该是让你更自信的过程？
+
+汤峥嵘：我认为那三年对我的价值是，给我今天创业绝对是奠定了基础，我完全知道怎么创业了。那三年是一个非常野蛮生长的过程，战略也不那么清晰，但恰恰是那个时候增长超快，每天忙各种事，不是跟业务沟通，就是招人，做新的技术，是一个不知不觉就做了非常多事情的阶段。我就有了新的体验，我觉得但凡一步一个脚印、有清晰战略去做事，可能自己的成长反而是不多的，因为你每一步都很稳，没有走出自己的舒适圈。
+
+互动时间
+
+你是怎么找到和自己价值观相符的团队的？欢迎在评论区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/09闲话家常（三）：纽约打工故事续集.md

@@ -0,0 +1,45 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            09 闲话家常（三）：纽约打工故事续集
+                            这一节只讲一个小故事，就把它叫做“纽约打工故事续集”吧。美国求学时期，汤峥嵘曾经在纽约一家小超市打工，很多年之后，途牛在纽约上市，汤峥嵘也去敲钟，机缘巧合下他又回到这个曾经打过工的地方，见到曾经一起工作的管理员。
+
+由此想到苏轼的诗《龟山》，诗人的境遇与这个故事也不完全贴切，只看前半首：
+
+我生飘荡去何求，再过龟山岁五周。
+
+身行万里半天下，僧卧一庵初白头。
+
+我这一生到处飘来荡去，到底要追求什么？先抛出一个哲学命题，上海财经大学人文学院教授李贵曾经在一场讲座中解读这首诗，当36岁的苏轼赴杭州任通判，再经过龟山镇，时间已过了五年。五年来走过大半个中国，再次经过此地，庙里的那个和尚已经长出白头发。我整日奔波，这位僧人始终安静修行，无所谓谁的人生更有意义，每个人都有属于自己的坚持和初心，如此而已。
+
+汤峥嵘：我2013年加入途牛，2014年公司就上市了，我还有幸去美国敲钟。正好说到这，当时还有个故事可以讲一讲。我那个时候还发了个朋友圈，很多人都说这个故事很励志。
+
+我在美国上学的时候不是在纽约打过工吗？就在那个韩国人开的小超市做收银员，打了一个暑期的工。然后呢，我 2014 年去纽约敲钟，敲完钟的第二天所有人都去购物了，我是没有购物的欲望，就一个人到处去纽约瞎逛了。
+
+逛着逛着突然间想到那个小超市，我大概还记得在什么位置，就想去那看看那家超市还在不在，我就跑到那去了。跑到我记忆里那条路上一看，那家店不在了，我以为就关掉了嘛，然后我就继续往前走了，只多走了一个街区，突然看到有一家小超市，跟我印象中那个超市还有点像，我就走进去了。
+
+进去一看，那个主管就是以前那个巴基斯坦领导，我一进去，他也把我认出来了。我当时的感受是什么呢？很复杂，我第一感觉就是，什么都变了，又好像什么都没变。
+
+因为我们当时敲钟的时候，我还是觉得很自豪的。纳斯达克敲钟的那个地方，它的会场并不大，里面有一个酒吧，会给大家弄一些食物吃，我找服务员要饮料的时候就和他聊天，他跟我说，来这的都是中国公司，他知道很多中国城市的名字。我们当时觉得非常自豪的，有一种我们中国人是万能的感觉。
+
+但是呢，突然间又回到了我 22 年前打过工的超市，见到了熟悉的人，发现这里的一切都没怎么变，还是这个主管，做得还是和 22 年前一样的事情。那个时候，他的老板已经不是那个韩国人了，老板都换了，但是他 22 年都在这个超市。他还跟我说，你看，现在收银的女孩，那是我女儿。他说的时候是带着自豪的感觉的。
+
+所以，我觉得这是一个特别有意思的反差。我们轰轰烈烈地干一番事业，我们把赚钱、上市定义为成功，我们好像觉得自己很牛。但是其实有另外一些人，他们移民到异国他乡，靠自己的努力，找到了一份工作，干了一辈子，然后自己的女儿也继续在同一个地方工作、生活，对他们来说这也是一种成功，甚至有更强的幸福感，因为这种成功更加稳定，更加踏实。
+
+22年前纽约市的一个最底层的打工仔，今天能够成为上市公司一员，在NASDAQ敲钟，有人说这个故事很励志。但我恰恰不觉得这是一个励志的事情。所谓的成功和幸福是什么？很难说。尤其是我们当时经历过这个高点，后面公司果然就是往下滑了，前面突然涨的太快了，大家都拼命地奔跑，反而落下了一堆东西。
+
+当你再回头的时候，你发现还是人家 22 年来就干一份工作，更能享受稳定的幸福。我相信他在这个店工作，无论换多少老板，新老板都得聘请他。就跟我第一份工作一样，老板都得走，我也不能走。因为他太熟这套东西了，这个地方也很稳定。我猜他跟当地的富人邻居也很熟，因为那个社区是一个富人区，他管着这个小超市，天天给这些邻居打招呼的就是这个人。他不仅是这个超市最离不开的一个人，可能也是社区里大家离不开的一个人。我觉得他会一辈子甚至下一代的一辈子都在这家店工作，为这个社区服务。
+
+那天发生了这件事，让我觉得特别有意思。在很多人眼里，去NASDAQ敲钟，应该是一件很成功很值得炫耀的事情。但这件事让我意识到，靠自己的勤奋，能够在异国他乡的一家店、一个社区找到一个属于自己的家，一辈子甚至几辈子都能稳定生存的家，或许更加成功，更加值得炫耀。
+
+我很感恩那天没有去购物，也没有在原来的小超市位置停下脚步，而是多走了一个街区。
+
+互动时间
+
+看完这段经历你有什么感受，欢迎和朋友们一起分享想法。欢迎在评论区交流。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/10管理的本质：如何把硬性政策柔性执行？.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            10 管理的本质：如何把硬性政策柔性执行？
+                            编者按：从这一节开始，我们进入第三模块：管理经验。如何理解“管理”二字？管理者应该怎样看待自己的职责？在日常管理中可以穿插哪些方法，让团队凝聚力、战斗力更上一层楼？在组建团队的过程中涉及到找优秀的人、划分组织架构、职级考核，甚至解决薪资倒挂的问题，管理者应该怎么办……从这一节开始，我们会聊一些管理的话题，和你分享汤峥嵘的管理经验。
+
+极客时间：技术人要转管理这个话题有点老生常谈了，结合你最开始讲的性格理论，我觉得第一步大家要先了解自己的性格，那除此之外，肯定还是需要一些实践。你觉得技术人转管理，有什么需要注意的么？
+
+汤峥嵘：技术人转管理可能第一步遇到的问题，就是由管事到管人的转变，这几乎是两种不同的方法。比如评判代码好坏是很清晰的逻辑，就看对还是错，优秀还是不优秀，代码写的漂亮不漂亮等等，这是管事。到管人的时候，他可能也容易用同样的思维方式去套管理，用一些比较分明的标签去评价人，把人当成事情一样去评价，去分黑白。一开始绝对容易踩这个坑。唯一的方法就是通过工作本身去练，在犯错中反思前进。
+
+极客时间：那从技术管理者要成长到 CTO，管理能力上会有哪些跨越？
+
+汤峥嵘：我先说一句，要做 CTO 的人，技术首先要强，不要误解 CTO 是个纯管理岗位，因为 CTO 是给一家公司把控技术方向的，如果这个人没有一定的技术深度，是做不好这个职责的。但如果你只是一个纯技术的人，做不到跟 CEO、COO 这些人讨论商业，这也不行，所以也要平衡。但我觉得更重要的还是技术，如果一个公司的 CTO 不懂技术或者技术能力不行，所有人心里应该很膈应吧，技术人员对这点还是很敏感的。
+
+如果你真想做好 CTO，别的先不想，首先确保自己的技术不能差。千万不要放弃自己对技术的追求和对技术的研究，不能变成一个纯管理岗位；千万不要放弃在公司里一些小的技术上的沟通，那个是让你保持技术敏感的一个很重要的途径。
+
+极客时间：回到最本质的问题，你怎么理解做管理？
+
+汤峥嵘：我认为做管理者，一个很重要的核心是把上级的刚性的、标准的需求，变成一个柔性的、可执行的方案，这才是管理的本质。
+
+上级往往传达的都是一个政策，一个只有数字的目标。举个例子，上级说，我们公司准备年底要裁员了，你的部门一共 100 个人，要裁 20 个人。要求给你了，你要解决的问题就是这 100 个人到底裁哪 20 个？这是很痛苦的事。但是这个问题的背后还有一个大的标准是，你得说服所有的人都认同，淘汰的这 20 个人是相对来说最差的 20 个人。因此本质上就要给这 100 个人排个队，我也是慢慢在实践中得到这个经验，我也跟同事讲，你只要想把这 100 个人排个队，总是能排出来的，你不要说你排不出来。
+
+你肯定不能首先就和领导说，我们部门是最优秀的，我们不应该淘汰人，为什么别的部门才裁这么点人？如果陷入到这个逻辑中去，你就完不成这个任务。因为你从内心根本就不接受这件事情。但是一旦公司层面做完这个决定了，大家首先得接受这个事实，因为你作为管理者，也得理解你的老板有他的难处。
+
+另外，大家一定要接受一个现实的情况，这个排序本身就不存在完全客观的情况。以前阿里有一个讲法就很简单，如果说一套打分机制能帮你把所有的分数排完了，那扫地阿姨也可以做管理了，或者今天 AI 就可以替代你做管理了，还要你干吗？对吧？你做管理，就是要你来给这些人打分，你就是标准。从这个角度来理解管理者，你就是来管这些人的，你决定了他们的去留、工资，你就有这么大的责任。
+
+我自己很早把这件事想通了，我的心态就好很多。在此以前总想追求一个完美的管理方案，想谁也不得罪，应该我打出的分所有人都叫好，老板也说好，员工也说好，后来你发现这根本不存在。慢慢我就悟出来了，作为管理者到底是为谁打分？其实是为你自己打分，你不是为你老板打分，不是说老板喜欢谁你就给谁打高分。你也不是为你的下属打分，你就是要建立自己内心的一把尺子，最后变成你在管理过程中的标准，并且说服你的下属。
+
+就像现在的产品都要描绘自己的用户画像一样，你要把你不喜欢的人的画像，和你喜欢的人的画像画出来，告诉大家，你鼓励什么和不鼓励什么。这个很有用，因为大部分技术人员心里都明白谁最优秀，你不讲他们心里也知道，那不如就把优秀的人做出案例，他做过什么优秀的事情，达到什么效果，作为管理者就要表扬一下。反正要做成案例，或者有数字指标参考，把这个弄出来，就好管理了。
+
+极客时间：这里面有个问题没太理解，你说管理者要认可自己的标准，这个要求是不是蛮高的？因为也许这个管理者他根本就没有自己的标准，他的标准也许就是他领导的标准呢？
+
+汤峥嵘：这个问题挺有意思，我给你解释个概念，中文中“管理”这个词，英文叫 Management，被翻译成管理特别好，为什么？Management 只有“理”这个意思，没有“管”的意思。这就是为什么西方人做管理比我们中国人更容易。
+
+“理”就是说这个桌子上很乱，我把它整理整齐，理就是整理、梳理的这个理。什么叫管呢？就是这块地方归我管。英文中有一个词叫 Owner，代表我是主人的这种感觉，或者是主人翁的感觉，我认为阿里在这点上讲得很好，它对管理者的要求就得有 Ownership。
+
+但是作为管理者，你先不要管公司给你多少权力，给你什么利益，首先你得从心里觉得这件事归你管了。在管理这件事上，我觉得中国人比较讲究秩序，就是我被谁管，或者我管谁，大家都希望明确。这个是我从美国回来之后，深刻感受到的不同。这就促使我发生转变，如果不理解中国文化里面的秩序观念，在这个文化体系下去做公司管理，我觉得可能管不好人。
+
+因为我觉得不太存在一个大家公认的一套标准，能被所有人都认可，每个管理者都还有自己的不同方式，因为人和人就是不一样的，内心一定会有标准，如果没有标准，真的以上级的意志为意志，我觉得是做不好管理的。
+
+当然，拿技术来说，大的评判标准是一样的，肯定是代码写得好、Bug 少、速度又快，这些是容易量化出来的。但是就管人来说，你一定得有自己的一杆秤，不只是关乎代码水平，还有你自己的维度，不管是工作态度、成长速度，或者其他好的工作品质。如果只盯着代码水平，把它过度量化了，会造成大家为了那个数字去想别的对策。比如你追求 Bug 少，那他就代码少写点；你要求能够准时提交，他就在评估时间的时候多预估一些工作量。人性就是这样的，这个是很难抗拒的。
+
+我认为，客观的并且可量化的工作考评，绝对不是挑选谁优秀的一个标准，或许可以筛选出来谁差。但是这个东西我们不定也不行，这个是底线。如果连这个都不定了，大家就可能觉得太放纵了。
+
+极客时间：回到你说的管理的本质，拿裁员这个事情来说，上级给了硬性指标，你会通过什么办法去柔性地执行呢？
+
+汤峥嵘：其实 VIPABC 在 2018 年底的时候做了一次裁员，比例还不小，那时候网上出了很多负面新闻。我们比其他在线教育企业提前经历公司的下降过程，确实裁那么多人是非常难受的。这是整个公司的问题。
+
+当时公司要求每个部门要裁多少人，我的方法就是帮被我裁掉的人介绍工作。因为产品技术人员还是有很多工作机会的。这个时候，我就不再是他老板的身份了，而是作为朋友给他一些建议，比如我有什么资源可以介绍给他，他有新方向了，我可以给一些建议和参考。我也会给他们讲一些方法。比如你有加入某公司的意向了，你就可以问老板，能不能跟未来的同事见一下，甚至吃顿饭，我觉得如果是一个好老板，人家也觉得你的建议是不错，可能就会同意提前来聊一聊，这个时候你就知道以后跟你共事的人是谁，氛围喜不喜欢，等等。我会给一些类似这样的方法。
+
+极客时间：互联网企业裁员，在现在这个时间点是进行时状态。很多人也会关心公司裁员的逻辑，一般企业都会说是末位淘汰。你现在站在 CEO 的角度来看，你怎么理解末位淘汰？什么时候适合做末位淘汰，你现在的创业公司（云柚智能）会有末位淘汰吗？
+
+汤峥嵘：我们现在没有定期的末位淘汰制度，因为公司现在太小了，小公司不适合这个制度。但我们从创业到现在一直在淘汰人，在平时工作中觉得这个人不行的，就淘汰掉。
+
+凭我的感觉，我觉得公司规模总得到几百人才适合做末位淘汰。假如你的公司在 100 人这个阶段，可能主要管理者下面就带 10 个人、20 个人左右，还是比较容易看清楚谁行谁不行的。但当公司大了之后，情况就会不一样，作为 CEO 可能必须得接受一个事实：每个经理、每个总监、每个主管，没有上面压力他可能不愿意淘汰人，这时候公司就会强制“换一换血”，淘汰一批人，这是做末位淘汰背后的原理。
+
+极客时间：接着裁员这个话题，企业扩张时期，往往一片欣欣向荣，有明确扩张规划的公司可能是有节制的招人，但也有疯狂招人的情况，当遇到市场低迷，或者融资困难等困境，往往又被迫裁员。员工受伤，老板内心肯定也会经历挣扎。你觉得企业是否应该有责任为一个员工3年后的发展考虑，在快速扩张期对扩招做好预判和规划？这个问题对企业管理者来说，是大家会面临的困境么？
+
+汤峥嵘：这个问题非常好。我正好可以解释一下我对企业、管理者和员工这三者关系的理解。首先，我认为企业是一个由一大堆标签组成的概念。这个概念是没有主观意识的，它随着环境的变化，而不由自主地变化着。所以我们不能简单孤立地看一家企业，而要看他在环境中所处的位置。其实企业的扩张和收缩，都是在应对外部变化甚至危机，都是为了生存，很多时候是无法控制的。动物为了生存，有时候要捕猎和扩张地盘，有时候要冬眠休息或养伤。企业其实做的是完全相同的事情。适者生存嘛。企业做得好坏，自然会得到市场的检验，没有必要用道德去评判企业。
+
+但是管理者就不同了。我前面说了，管理者的责任是把刚性的政策变成柔性的执行方案，把外部的不确定性变成内部相对确定的东西。管理者就是要把招人和裁人这两道难题做好，才能体现出他的价值。说具体一点，就是当外部环境要求企业快速扩张的时候，管理者要冷静思考招什么样的人，怎么搭组织结构。企业快速扩张起来以后，一定要花足够精力去管理团队，并且不断灌输危机感，告诉大家随时会裁员。当真的遇到需要收缩的时候，同样要冷静思考让哪些人离开，理由是什么？
+
+最后对于个体员工而言，我前面也提到过。不要奢望依靠任何人。如果觉得不公平，那就是运气不好，抱怨是一点没用的。如果是能力不行，抱怨两句就要有行动。
+
+最后回答一下你的关键问题。企业是否应该有责任为一个员工3年后的发展考虑。企业既然是个抽象的概念，就不可能为每个员工的发展考虑。企业和员工的关系就是简单的雇佣关系。但我认为一个优秀的管理者，应该为他的团队考虑这个问题，甚至不止3年。
+
+极客时间：职业成长过程中，随着你管理的团队越来越大、管理的职责越来越大，这个过程中，你经历过怎样的蜕变？有什么小技巧可以分享一下么？
+
+汤峥嵘：我讲一个可以操作的方法，就是不停的逼着自己想象自己就是老板，然后再想自己该怎么做事，这就是个小技巧。我以前是职业经理人的时候，比如老板要个方案，我都是提三个方案，方案 A、B、C。A有A的优点，但也有缺点。B、C同样。讲清楚各自优缺点，让老板来做选择，一般都是这么干。
+
+但当我把自己想象成老板的时候，我就不会这么做了。我仍然提三个方案，但我会跟老板说：如果我是你，我会选择其中哪个方案。这相当于我给了自己一次机会跟老板交流，如果老板比较厉害的话，还可以给我指点，我不就学到了吗？提三个方案的原因是，作为下属有义务给老板更多选择，同时自己也会体会到做选择是一个痛苦的过程，人越往上走，面临的选择越难。
+
+对于中层管理者，我还有一个体会，中层的管理者是连接作用，他要把向上的不确定性转为向下的确定性。因为管理者越往上走，他承受的不确定性越大。公司的创始人一定会面临某个阶段公司不知道怎么走的情况，做为中层的管理者要让下面人有信心，坚定地告诉大家该怎么干，该怎么往下走。
+
+你能承受越大的不确定性，你的级别就越高。你面对的只是一点点的不确定性，你可能就是一个比较初级的管理者。
+
+当你觉得你是这件事的主人的时候，你会冒着非常大的风险去管理这个事情，去做选择。你可能会搞砸，但是你也敢承担这个责任。如果有机会，我鼓励大家把自己放到主人翁的位置上来，因为即使你搞砸了，也是公司承担责任，不会有太多公司真的会怪到你头上来的，你还能锻炼一把，失败了你没啥大损失，成功了你有大收获的。优秀的管理者就是靠这种日常的磨炼成长起来的。
+
+互动时间
+
+总的来说，管理者都会面临这个问题，就是最终你得把公司面向集体的一个指令，也就是刚性的政策，落到下面具体每个员工头上去。这是汤峥嵘理解的管理的本质。
+
+你喜欢什么样的管理风格呢？欢迎在评论区留言。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/11为什么建议技术团队的组织架构按系统划分？.md

@@ -0,0 +1,75 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            11 为什么建议技术团队的组织架构按系统划分？
+                            极客时间：技术团队的组织架构建设话题，我一直很想聊，你了解的，技术组织架构的建设都有哪些常用方法？
+
+汤峥嵘：其实技术团队的架构无非是以下几种方式。一种业务导向的团队架构。假设你的公司有国际业务和国内业务，每个业务给它分配一个技术团队，这种分类方式比较垂直。但它的缺点是，团队可能经常重复劳动。
+
+第二种架构是统一的技术团队，全公司的需求汇总到一起，统一派工单。这种方式也非常常见，有很多公司在用。用这种方式的公司，说明它的 CTO 肯定是非常强势的，也许技术也是很强的，业务人员提完需求只能等着，要排队，具体排到什么时候他们也不知道。
+
+这种方法我觉得更适合稳定一点的企业，因为对这些企业来说，不管业务人员提的需求做成了还是没做成，应该对业务影响都不是很大，所以才会用这种组织架构。
+
+我比较喜欢用的架构是以上两种的组合。每个业务团队都配一个技术团队，但同时还有底层的技术团队。这里面的关键是，无论是业务团队还是底层技术团队，我要求每个团队都负责一个系统。拿途牛来说，我的组织上层有很多垂直的业务，比方说自助游、跟团游、机票、酒店等等，对应的就是自助游系统、跟团游系统、机票系统、酒店系统等等；底下还有几个共用的系统，比如说，搜索系统、价格系统、大数据中心，这些部门是要支撑全公司的。
+
+
+
+极客时间：关于技术团队的组织架构话题，网上也有相关的各种讨论，除了刚刚说到的几种，是不是还有按项目划分的形式？你觉得技术组织的架构有一个标准答案吗？
+
+汤峥嵘：我觉得技术组织的架构方法肯定是没有标准答案的。我的分配原则是，一个团队在做的事情要相对稳定，我不希望大家老是换来换去，因为这样没有办法积累经验。
+
+无论是对商业、产品还是技术类的知识，你都要有一个系统化的积累过程，这样才能进步和成长。所以我比较反对项目制，因为短期的项目一般很快就结束了，团队散掉之后，你就没有地方去做沉淀了。除非你要去做一个十年的长项目，但这种项目老板一般又不会批准。
+
+当然，并不是说完全不能做项目，但你得在系统稳定的时候做。系统是稳定的，项目是灵活的，这个没问题。比方说，企业底层的一大堆系统都已经比较稳定了，有一千个人都是固定的。这时候抽一百个人出来做项目，这是可以的。这就像搭积木一样，底层的积木先搭好，上面才能做一些变动。
+
+为什么我喜欢用系统来划分团队呢？因为我觉得系统是边界，这个边界定义好了，后面才不容易出问题。这可能跟我干了这么多年架构师有关，架构师最重要的任务就是把系统稳定地切分好。这个叫订单系统、那个叫支付系统，它们之间既有互动，又有一些差别，不能混为一谈。
+
+切分的时候，首先肯定要划定一些横向的系统，这些系统是大家都要用到的。做这些系统的人通常是比较偏底层的，底层的逻辑性特别强，所以我们匹配的人技术能力也要很强，他在产品、商业上弱点都没关系。公司切出一些系统来之后呢，直接用系统划分团队就是最好的，这样技术就能跟业务对接上了。
+
+业务这部分人（比方说做 APP 的人）跟做系统的人员又不一样，他得懂客户，他需要想象用户的使用场景。技术上，因为它依赖于最底层的系统，所以它的技术难度可能不是那么大，所以如果你脑子比较灵活，想法很多，就可以往业务方向发展。
+
+比如以前在途牛，价格中心就是一个横向的底层系统。那个系统是支撑全公司所有人的。它没有直接的业务对接方，它就是把价格这个东西做好就可以了。但是在它之上的很多业务，包括自助游、跟团游啊，他们都有自己的系统。这些内部业务系统业务方就可以自己去做了。
+
+把系统切割好还有一个好处，就是大家都很有责任心和归属感。因为每个系统有很明确的负责人，所以他会很有责任心，他不允许别人改他的东西。如果把这部分内容做好了，他们也很容易有很强的自豪感。我是喜欢去这么做的，我觉得对团队和个人来说都有好处。
+
+极客时间：你说的这个团队组建思路，有大小公司之分吗？比方说有的是几十人的团队，有的是几千人的团队，在组织思路上会不会有差别？
+
+汤峥嵘：差别肯定是有的，但其实原理上是一样的。大公司的系统很多，小公司的系统就少，但都是要去切分的。比如我们创业公司现在的研发人员很少，你可以理解为只有一个系统，甚至说这些人同时在做三个系统，但是因为人少，所以没有关系，管理起来仍然非常方便。
+
+但是设想一下，如果我们公司的开发人数达到了几千人，那我肯定会把不同的人分配到不同的系统上去，这样系统才能稳定。这还是基于那个前提，你得有个好的架构师。这就像我们国家治理一样，你得先把道路规划好。道路的宽窄不能是一样的，有些地方承载的人多，那道路就要宽一点，不然以后就会堵车。不同的地方，规划形式也不一样。
+
+再说回系统，每个部分功能不一样，做好切割，将来打架的事儿就少。最怕的是一开始切分没做好，后面架构师要进行重构。就像一条路，太窄了，用它的人又太多，没办法了，你就只能把路全部推翻，再来一遍，成本就很高了。如果前期切分做好了，以后有问题只是在系统内部一直迭代，不影响外面的人，那都好办。
+
+极客时间：所以在途牛和 VIPABC 都是在用你的这套方法去划分团队，在推行的时候有遇到什么问题么？
+
+汤峥嵘：我们在不同时期架构会有一些变化。比如说我们一开始在做途牛的时候，我们把 APP 单独拉出来作为一个团队。途牛那时候主推 App，大家（竞品公司）都在做移动，时间紧迫，就得有足够多的人快速赶上去。于是呢，就发生了App 把所有业务都做一遍，PC 端还要再做一遍，因为PC 也不能放弃。当时我们还没有底层这个东西（如价格中心）的。我就强制他们先自己做，自己内部做好分层，把未来调用公共平台的接口留出来，因为我知道未来底下的这层系统，一定是既能支撑 PC 也能支撑 App 的。
+
+在这个过程中一定会出现没做好分层，拆不掉的情况，我们当时打架是很厉害的。在局部我允许出现做两份重复劳动的情况，先跑业务，将来再解决合在一起的问题。比如在某些新业务上，为了赶上线时间，就允许App和PC各自把业务逻辑实现一遍。上线后再把公共的逻辑抽象出来，沉淀到底层系统中。
+
+我刚才讲这个做一层公共的底层系统支撑听起来好像很简单，但其实还是有一些挑战的。
+
+第一，到底什么是公共的？怎么界定哪些功能或服务要抽象出来？
+
+第二，这个底层系统做好之后，不同部门提的需求，在优先级上可能会有冲突。如果你只是在自己的业务范围内有需求，比如说我自助游只改我自己的代码，这个没问题。你有自己的人，自己去排个位就好了。
+
+但如果两个部门都有一些工作自己做不了，要给底层的系统提需求，这时候谁排在前面，谁排在后面？肯定会有冲突。我认为没有一个绝对好的机制可以解决这个问题。我当时的处理方法就是，我来排，你们都听我的就好了。工作的优先级问题，我负责跟业务的老板沟通，这样我团队的压力就小一些。
+
+我这么做是因为，我知道中间这层人的压力到后来都是最大的，公司大部分的需求都在我们这里做。等你逐渐发现很多东西都需要重做的时候，这些东西就应该放到公共的地方去做了，像阿里的“大中台”组织就是这么个道理。
+
+我为什么敢这么说呢？是因为阿里有行癫这样非常牛的人，他在一开始就把架构搭得很清楚了，在执行业务时候也很清楚。他指挥得好，中台搭建的速度就快。但如果公司的架构没做好，各个部门各自为政，这个大中台的转换就不会这么顺利。
+
+你想一想，一个部门他把自己的系统搞好了，你突然让他做中台，给“国家”做贡献，还没有财政拨款。那这个部门的负责人肯定会想，公司分给我的人，他就应该干我这个部门的事，凭什么干别的部门的事。而且你让人家做中台的事，人家的业务指标就受影响。他说我业务指标达不到，你能来帮我背吗？你又没这个能力，一句话就把你封死了。
+
+对这样的问题，如果说要提一点建议的话，我觉得作为 CTO，一开始就得留一点人出来，你不能把所有人都贡献出去支持业务。你得有点私心。但这里又有个度的问题，因为你留的人不能多到影响业务。这个平衡在哪，就得看每个公司的情况了。
+
+我觉得公司最后发展到比较稳定的状态，一般都是有底层公共的东西，上面有垂直的业务，VIPABC 也是这样的。但是在 VIPABC 的时候，因为我自己同时是 COO，我可以给我的技术团队提需求，和途牛那时候相比，没有那么大矛盾了，会好一点。
+
+互动时间
+
+你所在公司的技术团队架构是什么形式的？欢迎在评论区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/12技术、产品、业务三方关系？谁水平高听谁的.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            12 技术、产品、业务三方关系？谁水平高听谁的
+                            极客时间：我发现技术人和业务人思考问题的重点常常是不一样的，比如 CEO （更多指非技术出身的CEO）或者是销售、运营同学经常会觉得业务起不来，技术再好也没用。而工程师会觉得，不管业务怎么样，我技术要去做好。为什么会有这么大差别呢？
+
+汤峥嵘：公司里面不同部门都有不同的看问题视角。每个人站在自己的位置上，就会无限放大跟自己相关的东西，因为他要实现自己的目标，这就是主观性。就比如你情绪好的时候，你看到的天就特别蓝，心情不好的时候，就觉得今天好像哪里都不怎么样。
+
+具体来讲，业务人关注的就是业务量，因为他看不出你的技术到底能给他的业务带来什么价值。技术人呢，他们会说：没有技术拿什么支撑业务？当然应该把技术做好了。这种视角上的差异很正常。
+
+极客时间：这两种不同的思维一定会导致二者的沟通合作出现一些问题，具体可以怎么协调呢？
+
+汤峥嵘：关键是找到一个第三方作为“桥梁”，把这两端打通。我觉得这是 CTO 的一个很重要的职责。我们要花很多精力去跟业务人明确问题，然后协调解决问题。在快速变化的公司里，能力强的技术人员是有能力把业务上的一些问题先整理好的。不过现在的互联网公司里，这部分责任往往会跑到产品经理身上。
+
+极客时间：业务、技术，再加上产品经理，这就成了三方协作的问题了。
+
+汤峥嵘：对，因为产品经理恰恰是业务和技术中间的一个特别重要的桥梁。产品、业务、技术就是三角关系，一个常见的说法是“三角形是最稳定的结构”，其实对应着这三方，这个结论是不成立的。也就是说，产品、业务、技术这三方并不是在所有情况下都能形成一个良性的制衡关系的。
+
+那实际情况是啥样的呢？我们就把这三方具像化成三个人吧。我认为，这三个人谁水平高，另外那两个人就听他的，就这么简单。
+
+比如说，如果三方关系里有一个大牛级的产品经理，那什么也不用说了，另外两个人肯定都听他的。业务人会说：你太厉害了，你做出什么产品，我就卖什么东西。就像乔布斯做出 iPhone，产品好绝不愁卖。技术这一方也是，产品经理说什么需求，他就做什么需求。这样，技术人和业务人就都能做好自己的事情，这三方保持稳定状态。
+
+但是，如果产品经理很弱，那业务人和技术人肯定就会吵架。业务人会觉得技术不行，技术人会说产品讲不清楚。这种情况下，我们就没有一个稳定的平衡点。所以你看，产品经理这个位置挺关键的，但优秀的产品人确实特别少。相对地，优秀的销售（泛指业务方）和优秀的技术人很多，因为这两个相对来说能力要求比较单一。
+
+极客时间：看来在业务、技术、产品这三角里，产品经理起的是很关键的支撑作用，对这个结构的稳定性影响很大。也正是因为这样，这个三角很容易不稳定？
+
+汤峥嵘：对，因为优秀的产品经理很难找，所以，我在途牛和 VIPABC 当 CTO 的时候，都坚持要把产品经理放在我们 CTO 的管理线上来，相当于让产品听我的。因为我认为自己是一个能够打通技术和业务两边的人。
+
+如果分成三个部门，产品肯定有他们自己的分法。最后就变成什么样呢？这个三角结构在更高层的管理上更要打架了，因为相当于有三个强势的人都在指挥。
+
+我在途牛和 VIPABC 当 CTO 的时候把产品放到我这，就是为了减少三方带来的不稳定因素。但是我们的组织结构也要求 CTO 得有产品能力。
+
+我的做法是，把技术团队统一归成产品加开发。这样，我下面的技术 Leader 有可能是个技术经理，也有可能是产品经理。因为产品技术关系更近，产品和开发，都是“做东西”的人。它就是要做出个东西来，让业务方拿去用。
+
+打个比方，我们做出一个杯子来，业务方拿去卖。做杯子，从设计到开发，再到生产，这都是一系列的技术。我觉得它们本质是一样的，区别无非就是我们“杯子”的设计是产品经理做出来的，具体的“制作”是技术团队写代码写出来的。
+
+极客时间：除了你说的这种把产品和开发放一起管理的模式，是不是也有把产品放在业务那儿管的情况？
+
+汤峥嵘：我知道很多公司是这样的模式。业务人是老大，下面有一个产品、一个技术向他汇报，这时候就变成业务为主了。如果这个业务老大对技术是很有感觉的，这样绝对就 OK。
+
+淘宝为什么后来发展得那么好？我认为和陆兆禧做了淘宝 CEO有很大的关系。一方面他自己做过销售，很懂业务，另一方面他对技术的人是非常喜欢的，他就不停地提拔技术人出来做业务负责人。三丰（姜鹏）、行癫，一开始都是技术人，都是后来成了业务负责人的。三丰后来变成了淘宝的 CEO，行癫变成了淘宝的 COO。
+
+行癫负责淘宝的业务对淘宝的快速增长影响很大。我觉得，主要还是因为行癫确实是对整个淘宝的架构特别熟，而且淘宝的业务他从很早就了解甚至参与了。等他全面负责淘宝、天猫、聚划算之后，就很清楚应该做什么事，以及在哪些方面可以重点投入。这就是业务是三方中的老大，可以驱动产品和技术的情况，我认为这种状态是最良性的。
+
+因为产品和技术都觉得，我们老大还挺靠谱的，给我提的需求也好做，做完了马上就有效果，肯定就跟着他做。但如果是一个完全不懂技术的人当业务老大，提了一大堆需求，其他两方做不完，产品和技术的人这时候可能变成一伙了，合起来去跟业务人对抗。
+
+极客时间：这个例子很好理解。我的理解是，这种情况下就要求业务负责人的综合能力是比较高的。那在你待过的组织里，技术人会向业务方汇报吗？那产品经理呢？
+
+汤峥嵘：是这样的，我的组织里技术人是会向业务汇报的，产品经理呢，就放在我的技术团队里。比如说做跟团游，技术领导人可能是个产品经理，也可能是个技术经理，他下面有产品和技术（我每个团队下面都是有产品和技术的），这个人就相当于跟团游的 “CTO”了。跟团游的业务方完全不负责产品，有需求就找产品经理。所以产品经理就是要负责天天去跟业务沟通。
+
+我不建议把业务、产品、技术作为三个独立的团队。我也在这样的组织中经历过，觉得这三方特别容易吵架。我一直认为，在一个快速发展过程的公司里，不适合搭出一个四平八稳的架构。你的架构可以是有缺陷的，但是它也得有个长处，来支持你快速增长。最后你想快速发展，就是大家（三方）一起拼命奔跑，谁在跑的过程中领先了，跑的姿势还好看，他就突出出来了。到最后你会发现这个人真的很关键，他一个人的能力高低会影响一大半人。
+
+极客时间：前面我们聊了技术、业务、产品这三方的关系和组织划分。看来不管怎么划分，都是为了跑得快，公司能发展更好。
+
+汤峥嵘：我们的体系要做的是去给员工赋能，而不是束缚我们的员工。我觉得很多做技术的人特别喜欢定规则，他们自认为规则很好，但是这些规则常常反过来变成束缚了。
+
+就比如说写文档这个事儿吧。通常的规则是这样的：每做一个产品，大家开个会，从 PSD（产品详细说明文档），再到更细的功能需求，再到开发，再到测试，是要写一系列文档的。在公司里我就跟大家说，尽可能少写文档。你说你辛辛苦苦写了个一千页的产品需求，就算你不累，看的人累不累？有这时间，就把产品、开发、测试的三个经理关在一个房间里讨论，讨论到三个人都同意了才放出来，这个事儿就成了。讨论过程中，开发人员知道怎么开发了，测试人员也知道怎么测试了。你们觉得该补的一些核心文档，后面补一补就行了。因为市场变化太快了，等文档都写好了再讨论，肯定后面又得调整。
+
+我自己特别不喜欢看需求文档，而且大家应该都觉得看文档挺累的。国内的情况跟国外还不一样，外国人就是觉得写个文档出来很清晰。但是我觉得国内大部分人都没经过这么好的训练，还是习惯直接沟通。
+
+还有一个关键点是，有时候最核心的东西业务同学自己也没想清楚，辛辛苦苦做了这么久的文档，业务明天就推翻了重新来一遍，这不是浪费吗？我觉得比较合适的方式是，快速做出一个东西来，然后就拿上去试一试，不行就放弃。就是要快速试错、快速迭代，东西粗糙不要紧，关键是能让公司快速跑起来。
+
+极客时间：快速跑的模式下是不是出问题的概率也大？
+
+汤峥嵘：只要做东西就容易出 Bug，所以必须得在效率和错误率之间找到平衡。我那时候会实时盯着大家的这些 Bug。一个产品刚上线的时候流量不大，出点问题就出点吧，业务可能觉得影响不大，速度快可能比这个 Bug 率更重要。但是如果Bug会影响业务，刚上线就出了一大堆 问题，那肯定会被被业务投诉。所以这些都是需要技术和业务两方提前商量好、说清楚的。
+
+这里有个前提，就是技术团队修复Bug的能力要强。这个能力其实对技术要求挺高的。比如需要实时监控的能力。我经常讲，优秀的技术团队要能比用户先知道系统问题。我们用真实的一小批用户试错，等到大规模用户来临前，我已经把Bug修好了。
+
+我们技术人容易踩一个坑，就是沉浸在技术当中，又想做得快，又想做一个很好的东西，这确实成本很高，很难达到。但是用这个视角看问题，就很容易不清楚业务的需求。技术跟业务的关系是啥样的呢？用打游戏来打比方的话，业务和技术是打配合的。业务人员说今天要把刀，技术人就得今天扔个刀给他。技术人先不要想做一把多厉害杀伤力多强的刀，业务的人可能也不 Care 这个，他们就是想要把能用的刀，能大概砍几下就行了。
+
+那厉害的产品经理牛在哪儿呢？他跟业务的人聊完之后，就能明白在这种场景下业务真正的需求是什么样的。比如飞镖有时候就比刀的效率高，可能一个飞镖一下就能杀死十个人，产品经理就能说服业务方，其实飞镖更适合你。这时候业务的人才恍然大悟：还有这个玩意，挺好，我们要的就是这个。厉害的产品经理就是这样，需求看得很准。
+
+所以，业务、技术、产品确实相爱相杀，在一个快速发展的组织中如果有哪一方很牛，能纵观全局，带着另外两方向前跑，结果还不错的话，我觉得这就是比较好的协作模式。
+
+互动时间
+
+你目前是在业务、技术、产品哪个团队？欢迎你聊一聊和协作团队相爱相杀的故事。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/13CTO直接下属有60个总监，怎么管理？.md

@@ -0,0 +1,73 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            13 CTO 直接下属有 60 个总监，怎么管理？
+                            编者按：途牛总部在南京，业务飞速发展时期，公司创始团队也在考虑是不是搬到上海去，因为当时携程在上海，去哪儿在北京，都是在一线城市。而且，从业务角度来讲，大的旅行社都在这些大城市，途牛本身也避免不了要在上海招人，所以就在上海设立了一个办公室。最多的时候，上海和南京两个办公地，有 60 人直接向汤峥嵘汇报。为什么设置这么多的汇报线？直接管理这 60 人压力在哪？这一节我们聊了这些问题。
+
+极客时间：在途牛技术团队有 1500 人的时候，你说有六十人直接向你汇报，为什么是这样设置？这样的模式是不是就需要这六十个人都比较成熟，自身相对能够做很好的完成决策，要不然你的压力会很大吧？
+
+汤峥嵘：我的团队那时候都是差不多二三十人一个部门，我下面的总监团队大概有 20 多个人在上海，30 多个在南京，我一般一个月去上海一次到两次，去做单独沟通，平时就是靠邮件或者办公软件。
+
+你说的对，如果大家都不够独立的话，肯定会压力大，所以我认为要在流程上解决这个问题。一个是招人的标准，一个是淘汰的标准，这两个我要定好。第一步招人是最最重要的，我招人的时候是花了很大力气的。另一个关注的阶段，就是淘汰人，淘汰的标准我也会提前说好。技术能力是首位我先不说，在项目管理这块，我希望他们能让我提前预知风险，有什么问题预感到不妙，要提前让我知道，不要拖到最后一刻。
+
+我记得有一个总监，技术很强，但他是比较内向的人，有问题不爱提前暴露出来，每次我知道的时候已经变成大问题了，我就问为什么不提前说？我也跟其他人说，你们得帮他，不要帮他掩盖问题，最后等出了大问题的时候，再去淘汰他。我们是一个团队，你们今天帮他去掩盖问题，明天他可能就要被淘汰，你们就害了他。我的原则就是有解决不了的问题要提前让我知道，我可以来调节。
+
+如果他一开始就跟我说，老汤，我们这个业务方盯的很紧，我现在觉得这个时间赶不上了。那我就去解决嘛。越早告诉我，我就越有机会，去跟业务方沟通到底什么问题，因为他想做个事但现实情况确实做不到了，他自己可能也说不动业务方。但是我这个级别有可能用更低的成本说服人家。
+
+我经常说，你们找我做事，你们想好，为什么找我？因为你搞不定了，就这么简单，我比你级别高一点，我讲话就力度大一点，就节省内力。你们一定要把我当成资源， 把我用起来。但是反过来，你站在我角度，假如你判断这个事找我和你自己做是一样的，那显然就是浪费我的资源了。而假如你已经试了各种方法都搞不定了，请我出个手，或者说你已经判断出来，假如自己去讲的话，可能要讲三天三夜，换成我可能讲三分钟讲完了，这种情况当然把我用起来。
+
+我跟他们沟通，都是在解决问题，我是习惯性在解决问题过程中，去看每个人的潜质，在心里对他做个评价。如果我平白无故地去跟他去聊天，也聊不出啥来，大家肯定都说自己现在挺好的。我也是一样，老板找我来聊的时候，我肯定也不想说我现在有多难。如果总是表现很悲观的人，我反而不想留他，我认为人就是应该乐观的。一个人自我评价高、总能看到希望，我觉得是个好事。但再乐观的人总会碰到难题嘛，和我说就好了。
+
+如果我再搞不定，我心里也有个预案，做好准备，都是可以在风险预估之内。
+
+极客时间：但这不就需要你的一次次决策，就会占用你的时间和精力，六十个人如果经常都是这样不停的报问题，你的管理成本不就很高？如果在这六十个人上面再设一层，比如你只管理十个人左右，压力会不会小一点？为什么当时没有这样做呢？
+
+汤峥嵘：那肯定压力会小，但是我反而认为这些事情是我逃不掉的，那个时候必须要承担这些压力。我们那时候公司发展速度太快了，如果再在这 60 人上面加一层管理团队，我认为效率会变低。而且，当 CTO 离一线越来越远的时候，会真的看不见问题的。因为下属给你展示的基本上都是经过包装的真相。
+
+当有五六十个人的时候，有一部分问题我已经看不到了，但我还能保证看到一些很重要的问题。如果说只有五个 VP 向我汇报，大概率我只能看到 10%的问题，剩下的 90%都被他们给盖住了。
+
+极客时间：理解，我很好奇这六十人你怎么开会呢？
+
+汤峥嵘：那时候老板给了我一个特别大的办公室，我的办公室里放个很长的桌子，围一圈大概能坐 20 个人，剩下的人稍微站一站就行了。那时候我们开周会一般都是两个小时。
+
+极客时间：这么多人开会，每周要开两个小时，你怎么定义周会的目的？
+
+汤峥嵘：第一，大家确实需要每周有一个碰面的机会，让大家讲一讲各自的数据、思考。第二，我想让大家知道我重视每个人的工作，我在关注他们。每周我肯定会把公司的一些新动态给大家讲一讲。这个就是例行周会。对管理团队，除了这个会，那时候我还经常会办培训会，一周抽出一个晚上，把大家召集过来，给大家做一些管理培训，这是对周会的补充。比如我前面讲的职级搭建，大家对做这种考核不习惯的时候，我要让他们认同，关于阿里的一些管理方式啊在这个培训会上我都讲过的。在途牛和 VIPABC，我都有做管理培训会这个习惯。
+
+极客时间：你说这六十个人基本上能顶住一片天，那应该能说明你选人的能力非常强。招聘这一步常常会遇到面试看走眼的时候，你会怎么去面试总监级别的人呢？
+
+汤峥嵘：我面试的时候喜欢盯着一些细节去问。因为到总监级别，简历肯定都是很不错的。当然有的简历一眼看过去，没有相关经历，没有啥经验的肯定不行。但也可能这个人水平很高，只是他写不出来，那这种连简历都写不好的人，我也没办法，就不要了。
+
+面试的时候候选人会请他们稍微讲一下自己的工作，我会判断几件事，第一，从他经历中挑几件比较重要的事，看他到底是他自己干的，还是因为公司的光环，或者是他把别人的工作安到自己的头上，会追问一些技术细节。第二，我会把我们公司遇到的一些真实的问题直接抛给他，看他怎么解决。假设这个人能通过，后面如果发现工作与面试表现不匹配，我也会反思是我当时给他的问题有偏差，还是就是这个人不行，我判断错了。
+
+极客时间：我挺想接着这个招人的话题聊，你会喜欢什么样工程师，假设有几个工程师要竞争你下面的总监岗位，你会看什么特质？
+
+汤峥嵘：第一肯定是聪明，我觉得聪明是很重要的。但是要做到聪明应该不是一件难事，因为大部分人到了一定级别，智商都不会太差的。
+
+第二，就是我喜欢比较单纯的。单纯这个点绝对是看到这么多优秀的人的共通之处。有的人就是活在简单的世界里，他到这个岗位就关注自己做的事，攻克了一个难题就很开心，可能也不太关注外面的机会。能在 20 到 30 岁的年纪遇到一个让自己沉下来工作的环境，是好事。对工程师这个群体，绝对就是要沉得下来。
+
+第三，我喜欢责任心强的人，这也是很重要的。你给他布置一个任务，他要有主人翁精神，把事做成，我觉得现在很多人缺乏的就是责任心。
+
+极客时间：你会怎么去培养这些人？
+
+汤峥嵘：具有这些特质的人是很好培养的，就是给他一个比他的水平稍微高一点的任务，让他去完成。适当的时候给他一些方向的暗示，告诉他哪个大方向是对的，但是同时呢要让他觉得这是他自己努力做出来的，这会让他产生满足感。然后再多跟他们聊聊天，多点鼓励，他们就会很开心，也会更有信心。
+
+因为我经历过这个过程，我当初也是这样一个人，别人给了我鼓励我会觉得很开心，我就能不断往上走。其实优秀的工程师还有个特点，优秀工程师面子很薄的，很看重自己的口碑和别人的评价。这里我只说工程师啊，像很多优秀的创业者、企业家这些人还是要做到很能抗压的。
+
+你要是跟一个工程师说“你这么厉害，怎么连这个东西都搞不定？”优秀的人肯定很郁闷，他心里就会想，我一定把它搞定了，因为我这么优秀。作为他的领路人，就要学会激励的方法，让他不停地去追求更高的东西。
+
+我这样的人是特别能理解这种工程师性格的人。我认为一个好的 CTO 真的就是要做到自己的技术好，你才有同理心，才能知道那个技术好的人是什么样的人。所以我说管理是一个主观的活，因为你喜欢这种类型的人，你就会提拔和鼓励这些优秀的人，整个管理过程都是反应管理者个人的偏好的。大概率你是什么样的人，你就会带出什么样的人。
+
+极客时间：你在途牛管理的人都是工程师，是不是正是因为是同样的角色，你就能 hold 住这直线汇报的几十人？假设除了技术外，还有设计、运营等等需要你去管，就像 CEO 这个角色，就不太可能有六十个人直接向他汇报。可以这样理解么？
+
+汤峥嵘：你说的对，因为这群人的工作是同质化的，我就能相对扁平的管理，用一套方法就可以管理很多团队。如果还有很多非技术的团队让我管，按照这个模式我肯定就累死了。所以这算是在特定情况下我选择的一个方式。
+
+互动时间
+
+你是否有被领导鼓励过的经历？是通过什么方式呢？欢迎在评论区分享。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/14无边界访谈：创业思考与高手视角.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            14 无边界访谈：创业思考与高手视角
+                            编者按：汤峥嵘目前在创业，站在一家公司创始人兼 CEO 的视角上，他给我们分享了一些对创业的思考。同时在我们的采访中也发散聊了几个话题，不再单独成文，这几个话题可能是很多人在职场中都会遇到的问题，那不妨一起来看看高手视角是怎样的。
+
+创业思考
+
+极客时间：你最开始创业的时候，会给自己定目标说，用几年把公司做到多大规模吗？如果没有做到，心里会不会有落差？
+
+汤峥嵘：创业的人肯定大部分都有这样的期望，很想一年就变成一个很大规模的公司。但还是要着眼现实，现实的情况就是，很难在一年甚至三年这么短的时间，就达到一个较大的规模。
+
+我们创业的最开始，我就和团队说，我们这个事业起码要做 10 年。请团队来想象一下 10 年以后，公司会发展成什么样，会对社会有怎样的影响。但这个也说不准，也许 10 年过后，目标没有达到，还得再接着想下一个 10 年。对这个情况，我是有心理预期，可以接受的。
+
+其实，很多创业公司，他们最担心的可能还不是用几年时间能不能做大。很多时候像我这样的创业者会更担心过早投入，可能这个领域崛起的时机还没到，我们就投入大量的资源，但市场的反馈没有达到预期的话，反而变成“先烈”。等你把这条路趟出来了，别人开始入局收割，有太多案例了。这可能是现在一部分创业者的担心。
+
+经过这么多年，我也体会到自己身上的改变。比如之前在途牛、VIPABC，我都是带着团队去拼、去冲的，真的是起早贪黑地去拼。那个阶段就是自己身在局中，被市场逼着、被自己逼着往前跑的阶段。我虽然内心觉得，做技术要慢一点，要做到极致。真的热爱技术的人，可能都是这样的，但是我们身在企业中，有自己的责任，要考虑市场规律，有时必然要舍弃一些东西。
+
+因此这次创业，我也想做一些改变。有的人选的是已经比较成熟的市场，那一定避免不了激烈竞争。你如果不起早贪黑，竞争对手可能很快把你超越。我现在做的智能穿戴，技术和理念都相对超前，就相对可以慢一点，追求极致一点。而且现在整个社会开始有“慢”的趋势了，大家更追求品质，更关心自己的健康、生活质量。对我们来说是一个特别好的信号。
+
+极客时间：你是从什么角度去看各个行业、不同领域的发展趋势的，或者说你关注趋势么？比如你创业，为什么会选择健康大数据领域？而没有选择其他的？
+
+汤峥嵘：我的想法是这样，哪些领域好，有前景，对于这种大趋势其实每个人都能看得见。就像元宇宙，很多人入局，但轮到你入局不见得能做出什么东西来。而我呢，比较喜欢从小处着眼，从身边找机会。正好碰到智能穿戴这个机会，它就在我身边，是我能够得着的，就是适合我的。
+
+我剖析自己，我的优点是很理性，缺点是直觉不够，大趋势出来的时候我可能比别人反应慢一点。也许可能别人做了什么创新，把你颠覆掉了。商业就是这样，发展中必然有竞争和颠覆。所以我现在也在学习，看看书，我也挺好奇这些颠覆、被颠覆背后到底有什么规律，哪些事是我可以学习的。
+
+拿做菜做个比喻，川菜可能很多人都爱吃吧。假设要做餐饮，有的人很有大局观，能看到市场空白且可发力的地方，比如川菜在这个地方还没有的时候就打广告，让所有人知道川菜好吃，先把客户吸引来了，他再去做菜，这是一种打法。我可能比较保守，我得让所有朋友都吃一盘菜试试，好吃的话再去做更多的。
+
+这个没有对错，而是跟性格有关。靠直觉敢做决策的人，可能会嗅到市场的味道就立刻冲进去。像我这样实感型的人，可能喜欢准备好了再冲进去。
+
+极客时间：这个选择确实没办法在开始就知道对错、结果。我很好奇你现在因为身份的改变会让你看待公司的感觉不一样吗？很多公司发展到瓶颈的时候，增长疲软、市值下跌……可能会面临各种各样的难题。比如你说过途牛经过高速发展后来也经历下降的过程了，现在加上疫情影响，整个旅游行业发展也并不是很好；你也经历了VIPABC被平安集团收购。互联网大厂的收购案更多，如果一家公司没有蜕变好的话，可能就是要面临破产、收购的结局。在这样的时刻，被收购是不是一个好的选择呢？但是很多遇到过这种问题的创始人还是觉得不甘心吧。你现在自己创业有想过这些问题吗？
+
+汤峥嵘：这是一个对创始人心态，以及他对企业发展的理解，和企业生命周期理解程度的考验。企业和人一样，都要经过很多次蜕变。快速增长时期需要的能力、稳步前进时需要的能力，以及上市之后需要的能力都不太一样。像阿里这样的企业，做到这么大，蜕变过太多次了。
+
+那站在 CEO、创始人的角度，确实对能力、视野、责任感的要求都上一个台阶，我也在适应身份的转变。在看待一家公司发展的时候，创始人得怎么想呢？今天我还是这家公司的负责人，我就要尽心尽力把它打理好。但是当有一天我已经做不了这个公司的负责人的时候，那可能就得放弃，找一个能力更强的人来接班。难是难在，你看我今天说这话很容易就讲出来了，但假如真有那么一天，你再问我能不能接受，能不能交给别人？我可能也不能保证。这可能就是很多被收购企业的创始人经历过的煎熬吧。
+
+极客时间：经历过途牛和 VIPABC 这两个创业团队之后，你这次应该会更加从容吧？
+
+汤峥嵘：我尽可能先把我能掌控的事情从容地做好，假如未来真的出了可能让我纠结的问题，我也做过思想准备了，就可以避免陷入不好的情绪。
+
+高手视角
+
+一、企业一定有缺点，做好准备
+
+极客时间：你选择加入一家公司的时候，会关注它的缺点么？就像你加入 VIPABC，你知道它的优点，看到技术能发挥重要作用，你会同时关注它的缺点么？比如你看到某个缺点不可接受，就不去。你做选择的时候有这个想法么？
+
+汤峥嵘：我去 VIPABC 这家公司，能看到最纯粹的优点就是它的选课系统，很厉害，这个优点是吸引我过去的。其实任何人加入一家公司之前，肯定是看到了这家公司的优点，足够吸引你，你就会去。但我会在心里告诉自己，它肯定也会有缺点，只是我现在没看到，我得告诉自己得做好准备。任何事都有两面，一个优点的背后，肯定就是个缺点。
+
+二、薪资倒挂有平衡方法，但同时接受世界的不公平
+
+极客时间：像薪资倒挂这样的问题，你在的这几家公司应该出现过，有什么方案做平衡么？
+
+汤峥嵘：薪资倒挂这个问题是我们以前经历过的，在阿里的时候，我们就已经把它解决掉了。首先，接受这个现象，为什么这么说？因为它的本质是市场涨薪太快了。我们得接受两个人级别一模一样，但可能新员工比老员工薪资高。然后，用设置薪资带宽的方式去慢慢平衡，当然所有这些制度的前提条件是员工之间的薪资要保密。
+
+在阿里我们定薪资的时候设置带宽，至少分成高、中、低三档，比如都是 P5，会有初级，中级、高级。如果两个人级别完全一模一样，都是 P5 中级，但是一个是新来的薪资高，另一个老员工薪资偏低，我们调薪的时候就给老员工稍微多调一点，涨幅大一点，新来的人涨幅就小一点。不是把老员工的薪资一下子调到跟新员工一模一样的，而是逐渐往上调。因为你还要考虑人性，你一下调得高了，他可能猜到自己被倒挂，反而心里不平衡了。下次再涨薪的时候涨得少了他还可能产生落差。
+
+还是那句话，我们必须得接受，这个世界是不公平的。
+
+极客时间：我假设一个场景啊，假如你是我的老板，我有一天跟同事互相聊了薪资，聊完之后发现他工资比我高，我就去找你，说为啥我们俩级别一样，而他的工资比我高？你会怎么处理这种情况，有经历过这种情况吗？
+
+汤峥嵘：经历过。首先你来找我说这个事，我就可以不回答你。反问你，你怎么打听来的？公司明明是不允许互相透露薪资的，这是有规定的，你要对这个薪资不满意你可以离开。遇到这种问题，其实我没有必要进一步解释，因为解释成本很高，就算解释清楚又怎么样呢？
+
+如果比薪资，永远比不完，除了跟同部门的比，是不是还要跟别的部门比？凭什么销售比你工资高？销售也会问，凭什么做技术的就工资高？对吧？这个就太难比了，很多因素在里面。
+
+这个世界就是不公平的，永远存在吃亏的时刻。但是换个角度看，老员工有老员工的好处，老员工在公司里的人脉、业务熟悉度各方面都比新员工好，哪天要晋升的时候，他可能就被提拔上去了。然后他工资就比新员工高了，这也是一种平衡。这个时刻吃亏，下个时刻也许好运就降临了，就是这样。
+
+三、评判研发工作，我倾向定量考核
+
+极客时间：对技术人员的考核，之前有很多争议，比如看加班时长，看代码行数之类，这个东西在外面看起来批评多于褒奖，你怎么看程序员的考核机制？从你的视角看，你更倾向 OKR，还是用 KPI？
+
+汤峥嵘：像你说的，有的公司考核员工，看代码行数。我们所有人都知道如果看代码行数，你可以写一大堆注释，即使你把注释扔掉，也有人一行拆两行，大家总会有方法去应对这个考核方法。我们怎么能从代码行数看出来这个人优不优秀呢？这些确实都不是真正能够选拔出优秀人才的标准。
+
+但是，你要随便问一个程序员：怎么判断这个人是不是优秀？很多人肯定觉得标准是：他做出来的产品很牛、代码写得很好、Bug 很少……那什么叫好？什么叫少呢？大家都喜欢用定性的词。但要管理这么多人的话，就得定量。这是目前整个研发体系的悖论，大家都特想做出一套公平的体系，最好是能直接机器打分的，但假如要用这套机器管理你，你愿不愿意？肯定很多人又不愿意。一方面我们不愿意接受客观数据的考核方式，另一方面又对主观考核持怀疑态度。
+
+从公司管理角度，我认为公司还是要定量，虽然这不是程序员们喜欢的方式，但公司到一定规模，应该要有标准。同时团队管理者要为员工发展考虑，这样就比较倾向 OKR 的管理方式了，但我们之前的模式有点类似 KPI+OKR。
+
+我在这几家公司（途牛、VIPABC）的考核方式，都和公司整体考核体系保持一致，用的 KPI。但是我给技术团队的 KPI 是比较粗的。我首先给我下面的总监级的人定目标，把技术工作和他对口的业务联系起来，30%是和业务业绩直接挂钩的，这部分就是一个客观数字。剩下的 70%是技术指标，其中大概 50%要考核可量化的指标，比如系统稳定性、代码质量等等；另外 20%因人而异，针对每个人的能力模型做不同的要求，比如：如果这个总监带的团队技术比较弱，我会给他一个做培训的考核指标；如果这个总监和业务合作不是那么紧密，我会再增加业务方的满意度指标；如果是一个技术能力很强的人，我会希望他能多在团队内分享经验（提前沟通并确认目标），也会算作考核的一部分。
+
+到一线员工身上，设置更灵活。在和业务业绩挂钩的指标上不是设置 30%这么高的比例，可能 10%，让他们心里知道和业务是绑定关系的就可以。总体来说，我在给技术人定考核标准的时候，一定是因人而异的，一定有 20%是针对他个人的提升。
+
+互动时间
+
+采访的正文内容到这里就先告一段落了，在课程结束，汤峥嵘还有一封给所有学习过这个专栏的同学的信，感谢你的支持。最后，留一个问题给你：你为什么选择现在的行业、领域？可以分享你的思考吗？欢迎评论区留言。
+
+                        
+                        
+                            

专栏/超级访谈：对话汤峥嵘/结束语给技术人的一封信.md

@@ -0,0 +1,48 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            结束语 给技术人的一封信
+                            你好，我是汤峥嵘。最后一期分享我来做个结尾。
+
+首先，我非常感谢所有购买这个内容的朋友，也感谢极客时间的工作组，特别是编辑利莹。我是生平第一次录制音频节目。虽然有些内容反复录制了很多遍，但还是有挺多不太满意的地方。但是你的购买和留言区的留言，给了我很大鼓励。
+
+虽然这个内容被称为课程，但其实是一些对话，所以我觉得它的标题更准确些。既然是对话，那么内容可能就不那么严谨，而且涉及的内容也比较泛，可能会让你感觉有点跳跃。幸亏有编辑支持做了大量的整理工作，让我的经验分享更成体系。不过我希望能给你呈现出一些你之前可能不太熟悉的内容。无论是我之前在海外读书和工作的经历，还是有关性格、情绪等方面的知识，我都希望能给你一些技术以外的东西。如果你确实能有一点新鲜的感觉，那我觉得目的就达到了。
+
+大家在留言区的留言，我都看过了。从目前留言的比例看，大部分人对于性格分析很感兴趣，而且很多人把自己的性格测试结果发在了留言区。这说明很多人对自己的性格很感兴趣。但我这里一定要强调一下，不要给自己或他人贴标签，更不能因此就把自己给框住了，说这个工作不适合，那个工作更适合之类。
+
+我认为从群体的角度，性格和工作之间的相关性肯定是存在的。但从个体角度看，其实不确定性非常大。所以我认为 MBTI 这类的性格测试工具，它的最大价值是让我们可以有个窗口去看外面的世界，让我们了解这个世界是缤纷多彩的。让我们多一个维度去观察自己，观察同事，观察家人。让我们多一个方法去理解他人。如果你的工作需要你去扮演一个和你性格不同的角色，那就大胆地去扮演。让自己的人生更丰富多彩不是很好吗？只是记得，经常换回到自己的本色，经常回家充充电，该休息就休息一下。
+
+另外，我讲的有关生物情绪的底层逻辑，比如理性脑和非理性脑的理论，这些都是众多剖析情绪本质理论中的一种，也是我目前知道的比较详细的理论，所以分享给你。但我觉得科学就是要保持开放的心态，做好随时被更合理的理论推翻的准备。所以我也鼓励你多去看看一些比较新的研究，让自己永远保持着一颗好奇的心。这方面我比较喜欢听吴军（硅谷投资人）、华大基因的尹烨（著有《生命密码》）、媒体人梁冬，还有罗胖和得到上的一些内容，也推荐给你。
+
+我现在创业做的项目是基于大数据人工智能的健康管理。对健康知识的积累也是我在创业过程中不断完成的，很多内容我之前是完全缺乏认知的。而在我更了解人的生理、健康密码之后，我才知道“健康”两个字的重量，因此很想跟你分享一些健康相关的知识，希望你也能更关注自己的身体，重视健康。
+
+首先是心脏健康。很多年轻人认为自己心血管很健康，不会有心脏问题，像猝死这样的事和自己没半毛钱关系。但实际上，90%的猝死是心律失常导致的。而心律失常，有些是心脏和血管疾病引起的，还有些是因为焦虑、愤怒等情绪引起的。现代人压力越来越大，后者导致心律失常的比例也越来越高。建议你去看一看医学博士杨进刚的一段演讲，他说“愤怒可以使心脏病风险在 2 小时内上升 750%”。所以如果你感觉心脏附近不舒服，一定要重视。
+
+一种方式是去医院检查，背一下 24 小时 Holter（动态心电图监测），等于给你做一个 24 小时的心电图。当然背 Holter 不是很舒服，而且检查窗口也只有 24 小时，时间不够长。我们希望能更长时间监测心脏（心脏相关疾病的检出率，时间越长越有保障），也就是我现在创业在做的事，把监测仪器做进衣服，可以长期穿戴，而且很舒服。我们已经发现，有些人一喝咖啡或者茶，甚至奶茶，就会发生心律失常。如果每天只有一两百次心律失常，那还好。但如果到了 500 次以上甚至 1000 次，其实就需要注意了，这已经是亚健康状态了，而医院一般对 1000 次以下的心律失常都不认为是疾病。所以我认为定期检测一下，可以非常有效地减少猝死的风险。
+
+其次是因为打鼾而引起的呼吸暂停。呼吸暂停会导致睡眠期间血氧饱和度不足，大脑缺氧，严重的甚至会窒息。亚洲人特别是偏胖的人群患呼吸暂停的比例比较高。呼吸暂停分为 3 个等级，轻度、中度和重度。一般到了中度或重度，可能就需要做手术或者使用呼吸机了。但是很多人缺乏这个常识，甚至有人认为打呼声音响是睡得香。我们看到了很多人面临这方面的健康难题，也确信这是科技能发挥作用的地方。因此如果有人发现自己打鼾严重的，我非常建议去医院做一次睡眠舱的检查。睡眠舱检测虽然很专业，但体验很差，头上、脸上、身上要插满管子（一定程度也会影响你的睡眠）。我们希望能做出一个不用插满管子也能达到医疗级测量的产品，于是智能睡衣产品就出现了。如果有人关注大数据健康领域，欢迎体验交流。
+
+第三个问题是缺乏深睡眠。睡眠通常分成三个深度和阶段。最深的叫深睡眠期，这时候脑电波很慢，也叫慢波睡眠，这是最放松的阶段；其次是浅睡眠期；最浅的阶段是快速眼动期，也叫 REM（Rapid Eye Movement）期。在这个阶段，脑电波比较活跃，眼球会快速转动。做梦往往在这个阶段。一般来说，人的睡眠从浅睡眠阶段开始，逐渐进入深睡眠阶段，然后再回到浅睡眠，最后到快速眼动阶段。这样就完成了一个睡眠周期。通常一个周期平均 90 分钟，一个晚上有 5 个这样的周期。开始的几个周期，深睡眠会比较多些。越往后，深睡眠就越少。-
+
+
+现在科学家发现，缺乏深睡眠会导致患阿尔兹海默症（也就是老年痴呆症）的概率大幅提升。因为科学家发现阿尔兹海默症患者的大脑中，有一种叫β淀粉样蛋白的沉淀比较多。而深睡眠期间，会发生一个脑脊液清洗的过程，也被戏称为“洗脑”。在这个过程中，β淀粉样蛋白会被清洗掉。换句话说，缺乏深睡眠，就不容易清洗β淀粉样蛋白，也就提升了阿尔兹海默症患病的概率。而目前呢，阿尔兹海默还没有好的治疗方案。而且一旦阿尔兹海默发病进程启动了，就不太容易逆转了。所以大家真的要关注自己的深睡眠。
+
+我认为缺乏深睡眠这个问题，从事技术和互联网的人群会比较多一些。因为大家都是偏脑力劳动者，缺乏运动。白天动脑过度，晚上就容易做梦。我曾经就非常缺乏深睡眠，一开始用手表手环测，没有发现这个问题，数据都是 1-2 小时深睡眠。但用我们的产品测，发现一晚上的深睡眠经常不到 10 分钟。后来我专门去医院做了专业检测，确认就是这么少，那我就开始紧张了。但是我通过科学的训练，现在已经把自己的深睡眠调整到了 1 个小时，甚至接近 2 个小时。
+
+我这里分享一点经验。一是要多锻炼，也可以练习站桩冥想等活动。马云的太极老师阎素杰大师曾经给我们公司的人开过一个 21 天的站桩初级课。很多人都反映练了以后，睡眠有改进。我自己的数据也特别好，连续好几天达到过 1 小时 40 分钟，20%左右的深睡眠。这几乎是从来没有过的。另外，室温很重要。美国睡眠协会建议的最佳温度是 15-18 度。现在我夏天的时候就开足了冷气，然后盖大棉被睡觉，效果确实好。也可以在睡前 30 分钟泡个脚或洗个热水澡，让体温先上升，等睡觉的时候，体温迅速下降，也可以达到同样的效果。
+
+再有，就是要养成有规律的睡眠。倒不一定是要早睡。有人习惯早睡，有人习惯晚睡，每个人都有自己的生物节律，或者生物钟。你要试试找到自己的节律。习惯晚睡的人，早睡了反而睡不着。因为身体的生物钟一直在抗拒，因为还没到睡觉的时候。现在很多人出现的问题是等到了该睡的点，反而没有了睡意。有科学家提出一个“黄金 90 分钟”的理论。就是一定要把 5 个睡眠周期的第一个睡眠周期睡好，后面的自然就好。而且这5个睡眠周期的规律是，越到后面，睡眠深度越浅。因此如果一定要牺牲睡眠时间，可以牺牲一点后面的，但一定要保证第一个睡眠周期的质量。
+
+最后一个健康问题是心理或情绪问题。这其实是现代人普遍的问题。大家可以通过心理量表进行测试（我们的智能衣也提供此类功能）。我在前面讲过多次，人在被情绪影响的时候，很容易做出不理性的判断或选择。所以了解一下自己的心理状态，对于我们回归理性还是有帮助的。当然如果发现自己有较强的焦虑或抑郁情绪，我强烈建议还是要去医院或者心理诊所看看。其实当我们接受了自己心理上有问题的时候，我们的问题已经好了一大半。很多人会害怕自己的心理问题被人发现，导致心理负担更重，这种情况更容易加重病情。因此你自己一定要了解自己的心理状态。
+
+好了，一口气把这多么健康的知识分享给你，可能需要一点时间消化。以后有机会，我再给你分享更多的健康知识。那么这个专栏今天就在这里结束吧。借着健康这个话题，我也祝所有人身心健康，工作顺利，家庭美满，生活幸福！再见！
+
+最后，希望你能花两三分钟填写一下这份问卷，非常期待能听到你对这门课的反馈。
+
+
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/00开篇词蚂蚁集团玉伯：人生不设限.md

@@ -0,0 +1,62 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            00 开篇词 蚂蚁集团玉伯：人生不设限
+                            你好，欢迎来到《超级访谈：对话玉伯》这个专栏，我是专栏编辑利莹。
+
+专栏缘起蚂蚁 A 空间
+
+3 个月前，我在蚂蚁 A 空间一个会议室见到语雀创始人、支付宝体验技术部负责人玉伯，终于开启了这次采访。
+
+玉伯真名王保平，有一个被人熟知的标签——前端大牛，他在淘宝时期曾经作出过前端领域很火的框架 SeaJS、KISSY，之后也一直带领团队通过开源做了很多技术产品，包括 UI 设计语言 Ant Design、数据可视化框架 AntV 等，是一个妥妥的技术大咖。另外，玉伯还有一个慢慢显现的标签——产品新星，他对生产力工具情有独钟，文档产品语雀是他的作品。他曾经说自己有三个梦：技术梦、产品梦、自由梦，“产品梦重要的不是做事的方式，而是做成事情本身”，他把在大公司内部做创新产品称为内部创业。
+
+从技术到产品，玉伯都在尝试。我问他“从技术人到产品人的转变过程中，你遇到过哪些困难，你的思考方式会不会有什么转变？”玉伯分享了他的逻辑。
+
+大众意义上，语雀才算产品，但这个理解也许有点狭隘，因为技术本身也可以是产品，玉伯一直以做产品的心态在做技术。曾经疯狂做开源，对开源技术他也是当成产品去做的。因此，所谓身份转变，可以说是从技术产品转向业务产品，而从技术产品到做业务产品最大的变化，就是对技术、产品、运营的整体理解更有层次。
+
+玉伯与产品的不解之缘，并非从语雀开始。2008 年加入淘宝后，他曾参与淘宝内部赛马，跟团队搞了几个月创新产品后惨败，失败后回到 Java 团队搞技术。但因为创新产品之心不死，2010 年到 2011 年，他实际上一边做技术，一边继续摸索创新产品。他和同事一起做了一个图片社交产品，想做“中国版的 Pinterest”，最终这个项目里的小伙伴选择出去创业，玉伯选择留在阿里。又剩下他孤苦伶仃一人，最后转去支付宝。
+
+一个产品能诞生、突破荆棘成长不是一件容易的事，玉伯像坐过山车一样几度起落地折腾，也让他看清两点：一、技术是工具，是要为产品服务的；二、单枪匹马难成事，有团队才能走得更长远。
+
+玉伯加入支付宝后，创建体验技术部。他带领这个团队一路狂奔，在创新产品这条道路上越走越远，也越走越有方向。其中故事有成有败，在此次采访中，他也对这些或成或“败”的项目，以及自己一路走到现在的经历没有保留的一一做了分享。
+
+加入阿里前的故事
+
+在这里先讲一讲他加入阿里前的故事吧。2008 年加入淘宝 UED 是他职业生涯里很重要的一段经历，也是转变的开始，在加入淘宝之前，他就已经在关注用户体验。
+
+当中科大很多本科同学都在准备雅思、托福，想要出国的时候，玉伯发现自己觉悟晚了，自己的学分已很难申请到国外学校的全额奖学金，家里的经济条件支撑不起出国读书。他最终选择在国内读研，保送中科院物理所硕博连读。
+
+研二开始进实验室，要做一些光学材料的研究，在实验室废寝忘食的经历很难忘，有时候做实验连做几天，就直接在实验室里睡。实验中间涉及到大量的数值计算，这个时候开始需要写程序了，玉伯对计算机编程真正感兴趣也就从这个时候开始。处理实验数据要寻找规律，要求研究员有很强的数据处理能力，玉伯在这个过程中升级打怪，感觉自己天赋好像还不错，这种自我认知加上周边人的认可让他充满信心，这也是他真正入行计算机的一个原因。所以当他意识到好像写代码比写 paper 有意思多了，就在心中萌生了退学的想法。
+
+研三退学后，他进入中科院软件所工作。在软件所工作的三年里，做的事情很杂，除了做技术，他还学习了设计、交互，并对用户体验产生了浓厚兴趣。在那里，尽管玉伯的工作压力不算大，但个人的成长压力很大，因为他看到互联网正在改变着身边的同学、同事，最直接的体现是在工资上。而对当时的互联网人来说，梦想的殿堂是微软、Google等大公司，因此，他也曾应聘微软的用户体验岗，但在最后一面被刷掉了。
+
+后来玉伯才尝试投递淘宝 UED 的岗位，2007 年投完，两三个月没有回复，一直到他辞去软件所工作，到 2008 年 1 月份才收到淘宝面试电话，于是一个人从湖南跑到杭州面试、入职。后来才知道，这中间等待的三个月原来是因为他的简历邮件被过滤到垃圾箱，他的主管过了三个月才看到，差点错失一个面试题满分的人。对玉伯来说，最初加入淘宝，其实一开始并没有非要做前端，更多是觉得先有一份工作，而到此刻为止，玉伯才算开始他的西行之路，更深入地接触前端、体验和产品，逐步实现自己的三个梦。
+
+这是他加入阿里之前的故事，加入阿里之后，一方面依托平台的力量，一方面也是依托自己的力量，积累能力与作品，不断创造一个个向上的转折点。具体的故事，就在专栏里和你相见吧！
+
+专栏规划
+
+专栏分为技术、产品、管理三大模块，交付玉伯的经验和洞见。采访速记超过 16 万字，最终整理为近 8 万字的专栏和你见面。极客时间还向玉伯提出诸多问题，比如：
+
+
+作为前端圈子里的大牛，你是如何看待前端的价值的？
+互联网浪潮退去，客户端工程师何去何从？
+你探索了很多产品，你怎么理解产品经理的角色，自己又是如何进阶的？
+分清什么是反馈，什么是需求，为什么说这是产品经理的第一课？
+一个产品从 0 到 1 难在哪，从 1 到 100 又有哪些必要条件？
+对于文档产品语雀，你的最终畅想是什么？玉伯也将首次谈及。
+支付宝体验技术部能在蚂蚁内部保持独特性，并让外部同学向往加入，你都做了哪些努力？
+……
+
+
+针对这些问题，你会从接下来的访谈中找到答案。
+
+每个人都是独一无二的个体，那些成功背后的故事也许并不特殊，但其动人之处在于，每一次面对面的经历，都引导我们走向思考，比如这次它引导着我思考一些“最初的”问题：人生的意义是什么？我们如何与世界发生更好的连接？相信你在专栏中也能慢慢感受到玉伯的人生观。
+
+谢谢你看到这，接下来每一篇内容我们都会以访谈形式展现，欢迎你多发表看法，如果你觉得内容不错，也欢迎把它分享给你的朋友。
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/01从页面仔到工程师，前端到底在发挥什么价值.md

@@ -0,0 +1,100 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            01 从页面仔到工程师，前端到底在发挥什么价值
+                            玉伯在前端圈子里摸爬滚打十几年，他对前端价值的理解是什么样的？在他眼里，前端到底是一个怎样的岗位？我们带着这样的问题向他提问。支付宝体验技术部是前端同学最希望加入的团队之一，玉伯带领这个团队做出诸多创新产品，一定程度也能代表前端团队的边界拓展方向。因此我们希望把玉伯的理解交付给你，也许能给你不一样的视角。
+
+
+
+极客时间：经过你这么多年在前端方向的实践，你觉得前端的核心价值到底是什么？
+
+玉伯：前端的核心价值，可以等同为一个问题：“公司为什么需要前端团队？前端团队因何而存在？” 我找到的答案有三点。
+
+第一点，前端可以为公司降本增效，这是一个基本盘的价值。一个公司要做互联网产品，可以采用外包的方式，也可以采用自建团队的方式。为什么阿里等互联网公司采用了自建技术团队，核心原因是，自建技术团队，可以让产品研发更快，质量有保证，整体可持续发展。长期来看，互联网公司自建技术团队，可以大幅降低产研成本并保证高效产出。
+
+组织设计上，技术团队经常会集中在一起，前端团队往往也会集中在一起。集中可以带来效率提升。假设一个业务需要 30 个前端来支撑，放到我这里，可能只需要 20 人就能满足业务需求。因为集中化管理，可以复用专业经验，我们知道如何更高效更专业地支撑业务。前端团队放在一起，在判断需求的优先级时，全局取舍会更自然发生。当前端分散在各个业务时，好处是能形成自闭环，但会带来一个常见问题：零散前端往往会被迫接好多需求。一旦前端是集中的，同时前端人员整体又紧缺时，面对业务需求，前端往往就不会再无条件接需求了。在需求的取舍过程中，就砍掉了很多没必要做的需求。砍需求往往是对业务的最大提效，不做一些需求，反而能提升需求质量，最终让业务做对需求。
+
+但如果自己就是业务方，独立负责一块业务，很多 Leader 肯定就会想自己闭环最好，不然还得等排期。还不如自己直接招几个人，这样更高效，这是人性。但实际上，需要大家更客观去看。早期自闭环，可以让业务从 0-1 更高效。发展到一定阶段后，特别是各个业务板块需要互相关联时，集中化的技术支撑，往往能复用专业能力，整体业务效能会更高。
+
+我现在更能理解一句话：分工是整个社会效能提升的关键。工业社会的分工极大提高了社会运转效率。以前农业社会衣食住行所需要的东西都可以自己生产，这叫做自闭环，效率是极低的。正是因为有了社会分工，整个人类社会才飞速发展。
+
+降本是最近几年才凸显。现在不少公司开始提经营责任制，各个 Leader 会更意识到要省钱。举个例子，设计师对业务来说很重要，但业务如果自己去招一个创意设计师，往往不如用设计大团队提供的创意同学，这样会更省钱。统一的设计或前端部门，可以整体统筹，议价能力也更强，可以非常实在地降低成本。
+
+简言之，前端团队的存在，是因为技术专业分工能带来整体效能的提升。同时前端团队往往会是一个整体，集中化可以降低公司的整体成本。
+
+极客时间：刚刚聊到增效，那你们怎么去和业务负责人沟通，能让他们感知到，实际上你们是在帮他提效的呢？
+
+玉伯：需要互相建立信任。如果业务方提什么需求你都拒绝，肯定不行。一方面要去接需求，一方面也要有勇气跟对方说我们的想法：为什么某个需求我们觉得不靠谱，为什么当前腾挪不出来同学来做新需求。可以主动把人员投入透明出来，让业务方知晓我们把人员都花在哪了。整个过程中，核心关键点是，如何让业务方相信前端的专业度。前端是技术岗位里离用户最近的，不少优秀的前端工程师经常具备不错的产品思维，往往能给到业务一些靠谱的建议。当这些好建议有一起两起，逐步跟对方开始有互信，开始建立正循环时，一切就好了。要相信，我们的专业，我们的善意，对方是能够感受到的。
+
+带的团队比较大时，与业务大 Leader 的互信非常重要。具体业务 Leader 可能会抱怨“前端团队老不接我的需求”，但是业务大 Leader 往往会更有全局思维。资源投入的本质是优先级管理，上一个台阶看问题，很多优先级就能决策出来。
+
+极客时间：前端团队放在一起，能够给业务更专业的指导或者专业的反馈。看起来你带的团队，前端还是有话语权的，前端的这种专业度是如何建立起来的呢？
+
+玉伯：这取决于前端 Leader 的想法。我一直有个观点，前端并不是为后端服务的，前端跟后端是平等的，共同服务于一块业务。首先自己心态要摆平，同时跟后端也要说清楚我们的想法。有些后端老觉得这是他提的需求，前端做就好了，但是需求不应该来自后端，而应该来自业务方。不少情况下，业务没有专职 PD（产品经理），后端兼了 PD 职责，比如在不少中后台业务场景，对这种情况，也要分开来看这两个岗位的需求。摆平位置之后，前端和后端一起以合作伙伴关系服务于某块产品或业务。
+
+和后端的关系梳理清楚后，更难的，是如何能跟业务达成互信，这取决于你对产品域或业务域的了解程度。要能和业务对得上话，不能纯粹只是一个页面仔，要成为懂业务的工程师。鲁肃担任蚂蚁 CTO 期间，我刚过来蚂蚁不久，看到各种业务类型，琳琅满目，要学的东西很多。在了解业务之前，早期我也是个前端资源，后来随着越来越熟悉业务，对不少产品开始有深度理解，慢慢有了自己的判断，才感觉到能发挥的作用更大。
+
+但我同时发现，前端再理解业务，一般来说都很难超越后端，因为后端掌握真正的业务逻辑。前端懂业务远远不如后端懂业务来得这么自然，但是前端懂体验，这是我们的长处。我们其实对于一些交互设计、体验细节、对用户使用产品的体感会更有优势。后端很多时候不太懂体验，他们甚至会觉得功能堆上去就好了，但是堆功能，往往会带来糟糕的产品体验。
+
+衡量产品体验好不好，有好几个指标。传统常用的是 CSAT（Customer Satisfaction，客户满意度），很多行业都可以用。在 to B 领域往往会用 CES（客户费力度），用这个反向指标来判定用户使用产品费不费力。在 to C 领域常用的是 NPS（净推荐值），有太多介绍，不赘述。当我们能通过 CES 等专业指标去衡量产品体验，并能具体给出优化建议时，前端懂体验的优势就能体现出来。当我们体现出专业度时，大家就会尊重你、信任你。
+
+极客时间：刚才聊了前端对业务的第一个价值点是降本增效，第二个价值点是什么？
+
+玉伯：第二个价值就是前端有助于产品体验的提升，因为前端是最靠近用户的工程师，这个真的是前端这个岗位能够给到产品和业务很大的价值点。一个产品最终展示给用户的界面，都是前端或客户端通过代码写出来的。前端在这个过程中要调试，调试过程中对产品的感觉很重要。当感觉不对劲时，好的前端会去找设计或产品同学反馈，共同去思考是不是哪里没考虑周全，是不是某个细节功能点有问题。我们常说，当代码写不下去的时候，大概率是产品的设计逻辑错了，这时停下来去修改，对业务的价值是很大的。
+
+前端的体验优势，也有一个危机。老一辈的前端，有很多像我这种从物理、化学、生物等各行各业转过来的，是对体验有浓厚兴趣的一波人转行学做前端。这波老前端，普遍对用户体验的感知力很强。随着前端校招生源变好，大量计算机科班出身的同学开始做前端，最近几年有不少学算法的同学也来做前端了。这些科班出身的同学，整体特点更理性，更逻辑化，更像服务端开发，这些优势非常好。不足的是，不少新同学会对体验的感知有缺失，有像素眼、愿意写 CSS 做界面的同学越来越少。
+
+举个例子，之前我面试的时候，经常会出一道题，拿 CSS 实现的页面给候选人看，这个页面中间有些像素偏差，可能只差一像素两像素，我想考的是他能不能看出像素偏差，看他具不具备“像素眼”。给老前端看，一眼就看出来了，但是现在很多前端新同学看了半天都觉得没问题，现在这道题我都不敢拿出来面了。以前前端对体验的感知还是不错的，我们之前已经往前走了一步，使得设计者关注核心的创意和关键元素就好了。早期设计可能不需要出完整设计稿，只需要出关键设计稿就行了，剩下的前端就实现了，效率很高。但现在不行了，现在前端和设计的协作关系又变成了设计要抓还原度。这个现状，是当下前端天空中的一朵乌云。
+
+体验曾经是我们的优势，但是接下来慢慢也会淡化，目前我也在想一些其他解法。当下仍然是优势，至少团队里面还是有一半同学有这块的感知。现在一些前端领域的大会上，一些专家都在呼吁前端回归到关注体验，我认为这很重要。
+
+科班出身的同学只是对用户人机交互层的感知变弱了，在前端工程化和专业代码逻辑层，以及往计算机底层探索的能力，都全面变强了。整体来看，在朝着更好的方向发展。
+
+极客时间：降本增效、提升产品体验，前端在这两方面也都遇到来自业务方或者行业趋势的挑战。前端对业务的最后一个价值是什么呢？
+
+玉伯：第三个价值点，我最近几年有些感悟，发现前端技术开始真正为业务创造一些可能性。
+
+我举个例子，比如数据可视化领域，当时中国最有名的产品应该是百度的 ECharts（注：2018 年捐给 Apache），ECharts 的基本思路是一图一表，比如饼图、趋势图、气泡图等，都是先有图，再去实现这个图。2014 年，我们也想做数据可视化，但如果只是再做一个 ECharts，意义不大。当时我们就在想，可视化领域有可能的创新点会是什么？如何才能做出差异化竞争力出来？
+
+于是我们开始研究学术界的进展，发现其实上个世纪就有一个学术大拿，已经写了一本书叫《The Grammar of Graphics 图形语法》。很厚的英文书，我们团队几个人一起研究，看完之后觉得如果以语法的方式去做数据可视化框架，我们非常有机会超越国内包括国外绝大部分同类产品。
+
+当我们在 AntV 里，真的把图形语法实现出来后，发现跟 AI 领域可以天然结合。利用语法特性，能根据数据特征或用户指令，通过语法智能化生成一些图表，甚至可以生成全新的未见过的图表类型。这是产品方都没想到的，是技术给了业务新的可能性，并有机会成为一个产品亮点。
+
+类似竞品在国外有，比如微软的 Power BI、IBM 的 Watson 等，也是倡导智能洞察，用户只要说一句话“想看特定人群过去一年的留存率”，它就可以把趋势图等洞察给展现出来。当时做 AntV 时，我们压根没想到智能图表场景，后来做着做着发现居然可以让业务智能化，才开始意识到前端技术也能成为产品的核心竞争力。
+
+再举一个例子，大家可能都用过支付宝上的蚂蚁森林、蚂蚁庄园等产品。这些产品背后，是我们沉淀的一套图形互动技术。支付宝上不少应用已经不是传统前端应用，而是互动应用，具备不错的互动体验。基于这套技术，可以实现支付宝的五福、打年兽、神奇海洋等业务。这些互动应用可以做到较低成本研发（和传统游戏比），为支付宝的业务形态提供了新的可能性。
+
+总结起来，前端的价值有三点：降本增效、提升体验、创新可能。
+
+极客时间：经过这个过程，你觉得对于前端来说，大家的自豪感会更高吗，天花板会更高吗？因为逐渐有越来越多的事情可以尝试。
+
+玉伯：这是一定的，我们都逐渐从页面仔变成了工程师。身份的转变花了很长时间，2014 年-2018 年对我来说，我觉得自己还是页面仔，2018 年以后才能自称为工程师。
+
+Ant Design、AntV、前端工程化、前后端分离等事项，在经过 3-4 年发展后，到 2018 年才逐步显露成效。其他团队逐步不再把我们当成资源，会认可前端也是有技术厚度的，同时对效能提升和体验提升，也是显性可见的。
+
+2018 年起，我们也开始有一个倡导，让前端工程师往产品工程师方向发展，目前还在路上，只在语雀等少部分团队实现了产品工程师的倡导。语雀的不少技术人，喜欢写代码，同时也喜欢语雀，在用技术实现语雀过程中，还抱着对产品的热爱和见解。语雀的一些产品模块是前端工程师在负责，这是语雀的核心产品竞争力的来源之一。
+
+之所以语雀的前端工程师能成为产品工程师，有两个因素。第一个因素是全栈开发，语雀的主体是用 JavaScript 实现的，语雀很有可能是中国最大的 Node.js 系统，语雀 90%的代码都是 Node.js 写的。这意味着在语雀，前端不仅是前端，这个产品的后端实现、算法、运维等，前端工程师都在做，再加上对语雀的热爱，对产品有感知，前端写的代码是蕴含着对产品的喜爱的，在这种情况下，前端工程师就有机会成为一个产品工程师。
+
+前端人群里，还很容易出现优秀的产品经理。语雀的产品经理、钉钉的产品经理、微信读书的产品经理、飞书的产品经理，据我所知，都有不少产品经理之前是做前端的。
+
+当然，前端人群里，也有出现 CTO、CEO 等，虽然还不多。但我相信，数字化的大趋势下，有工程师背景的创业者，只会越来越多。前端从业者可以做的事情，也会越来越多。
+
+小结时刻
+
+玉伯总结前端对业务的三大价值，一是降本增效，二是助力产品业务的体验提升，三是前端技术逐渐可以成为产品的核心竞争力，为业务创造可能。其中，前端技术对体验的提升，在下一节我们会聊到，敬请关注。
+
+你对前端这个岗位是如何理解的，如果你是从事前端的工程师，你希望做哪些突破边界的尝试呢？欢迎大家一块交流，我们下一讲见！
+
+延伸阅读
+
+
+玉伯：前端的现状之痛及未来趋势
+淘宝玉伯引发 Web 前后端研发模式讨论
+
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/02何为体验：把简单留给用户，也把简单留给自己.md

@@ -0,0 +1,71 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            02 何为体验：把简单留给用户，也把简单留给自己
+                            2008 年加入淘宝前，玉伯曾在中科院软件所上班，在软件所的工作很杂，后端不愿意做的，他可能全包了，一边写前端，一边做交互设计，还要兼产品，那个时候开始他就对用户体验很感兴趣了。他进入淘宝时第一个岗位不是前端工程师，而是界面工程师。玉伯很早就开始关注用户体验，那么体验到底是什么，他如何理解这个词呢？到今天为止，用户体验的提升体现在哪，还有哪些做得不好的地方？他聊了聊自己的想法。
+
+
+
+极客时间：你怎么理解体验这个词？
+
+玉伯：一般谈到体验，大家都会想到用户体验，这是业界通俗理解，狭义讲就是用户使用产品过程中的人机交互体验。我们内部在讲体验的时候是把体验分为两层，第一层是用户体验，第二层是研发体验。用户体验就是让用户用得爽，研发体验是让我们自己爽。业界说法是要把简单留给用户，把复杂留给自己，我们的提倡是：把简单留给用户，同时也把简单留给自己。
+
+极客时间：你觉得在今天的互联网行业中，用户体验设计或者体验设计做得好的地方在哪里？有哪些你觉得做得还不够？
+
+玉伯：这个话题可以聊一下。我觉得做得好的，是守住了体验基线。以支付宝为例，支付宝每天有几亿用户，每类用户使用支付宝的场景都可能有所不同。在这么多使用场景里，如何保证不同用户能快速打开支付宝，能找到想要的功能点，能用完功能后回退到首页，能去探索一些新功能。在这么丰富的用户场景下，支付宝基本守住了体验地板，守住了体验基线。
+
+极客时间：体验基线是什么意思？体验基线这个词感觉还是理解起来比较模糊，就比如说我们看某个产品的时候，我大概知道它挺好看的，然后用起来体验也好。但是标准是什么？一种感觉吗？
+
+玉伯：体验基线就是体验地板，是体验默认不糟心。这个点看起来好像挺容易达成，实际上挺不容易。体验基线的提升是系统化工程，经常会比单点的体验天花板的提升更难。
+
+比如，在蚂蚁中后台应用大规模使用 Ant Design 之前，体验基线的提升几乎是不太可能的事情，因为需要推动每个系统单独去优化。后来 Ant Design 大规模应用后，我们可以自豪地说，只要用了 Ant Design 的中后台应用，页面颜值就上去了。虽然只是颜值提升，但实际上已整体提升了体验基线。
+
+体验好的标准，挺难定义的。Ant Design 有个长远目标，是使用了 Ant Design 的产品，就能“默认好看并默认好用”。目前“默认好看”的目标初步达成了，但从默认好看到默认好用，还在过程中。
+
+极客时间：那从好看到好用需要经历什么过程，需要怎么评判？
+
+玉伯：行业也没什么标准，只能说我的经验。去看一些中后台的操作页面，会发现其实很多时候，好用并不取决于长得是否好看，好用更多取决于产品的操作交互是否贴合业务场景。
+
+分享个 Ant Design 在设计过程中的一个坑。我们内部有一个客户服务系统，Ant Design 在早期追求排版布局的美观好看。为了好看、有呼吸感，排版会比较大气，错落有致。但这种设计，对整个客服系统来说，就很痛苦了。后来我们才理解，一个好的客服操作页面，需要页面信息密度足够高，方便客服人员在一个页面里就能找到各种信息并做快速操作。这种情况下，别看页面上密密麻麻的，密密麻麻才好用，宽松排版虽然好看，但并不好用。
+
+业界去讲体验不好的案例时，经常用的一个比喻是说飞机操作仪表盘是不好的体验，因为上面有非常多的按键，很不好用。但我要对这个说法打个问号，这很可能只是业界的一个谬误。如果真把飞机的操作盘简化成 iPhone 一样，那飞机可能就要失事了。要回到专业领域去思考，比如去调研真正在飞机控制室里的飞行员是怎么想的。我找过很多文章，到现在为止都没有看见真正从事飞机行业的人出来说话，都是一帮搞互联网行业的用户体验设计师在那里拿它举反例。
+
+所以从好看到好用，我目前更多在做的事情是，让特定领域的设计师深入业务。目前语雀的 UED 在语雀团队，设计师必须懂业务，得去研究用户的场景是什么、用户的高频操作是什么，然后再回到设计上，考虑怎样做到体验最好。在这个过程中，大家在保证操作效率和好用的基础上，同样要保证好看，这个好看是指多数人默认的好看，不是设计师一人觉得的好看。通常好看是更容易做到的，好用是更难做到的。
+
+在前端这块我们提过产品工程师的概念，在设计这块，我们也提过一个概念，叫产品设计师。我不大想提体验设计师的概念，我们更多倡导产品设计师。最终前端和设计，都要落回到产品上。做设计也好，做前端实现也好，有时候体验好了，产品也不一定好用，这是两回事。
+
+极客时间：这个怎么理解？体验好了也不一定好用？
+
+玉伯：体验往简单了说很容易，一方面好看，一方面好用。但这里面有太多分支，比如新手体验好了，可能老手觉得特难用，经常会有这种情况。
+
+好用，也很难定义。比如健康领域，我们觉得好用还是得跟功效相关。比如一个按摩椅，可以设计得躺着很舒服，体验很好，但是舒舒服服地按摩后，起来发现并没有缓解腰酸或腿疼。舒服的按摩椅，躺着再舒服，最终没有功效，那也是不好用的按摩椅。考虑功效后，体验会是一个特别大的话题。
+
+体验跟时间有关系，很多时候当下觉得体验优秀的产品，有可能在未来某一天会突然觉察到体验极其糟糕，比如抖音。体验跟人群属性有关系，不同人群对体验理解是不一样的，比如 QQ，工作族和学生族对它的感受也不一样。体验跟面临问题的程度有关系，就像医生看病，如果是容易治的病，医生态度、医院服务就是更容易感知的体验，这个时候去私人诊所可能会觉得体验更好，很多人围着你转，给你一种 VIP 的体验。但如果是难治的病，大医院的体验会更好，因为大医院有更高概率治好病。考虑有用，考虑功效后，很多产品要达到好体验，还有好长的路要走。
+
+在今天，体验不够好的地方，是体验本身的创新停滞。人机交互设计的创新，这些年有种停滞感。结合硬件比如 AR、VR 的发展，整体交互体验的创新也缺乏新意。从 PC 到手机的创新，特别是触摸屏的体验，是苹果带来的一个很大创新点，让人机交互更自然了。但是从手机之后，都是些微创新，甚至目前很多 App 的体验有倒退，整体趋同。这种同化的背后，是被已培养的用户习惯所裹挟。
+
+说下体验同化。打开美团和支付宝，你会发现长得差不多；视频号也越来越像抖音。哪怕张小龙很坚持创新，也没办法做出多大的不同，因为视频号最终要服务的用户和抖音用户有巨大交集。如果服务的用户是同一个群体，最后的体验设计就会趋同。目前国内体验的设计其实极大地被同质化，在海外还是有好多在体验上会做创新的产品。打开一些海外的 App，他们的设计还是挺有创意的。但在国内基本上做个什么新产品，长得都差不多。
+
+极客时间：这个现象也要两面看，经过时间的沉淀，大家默认这是体验好的。然后如果一个新产品它不是这样的体验，大家可能反而觉得体验不好。
+
+玉伯：趋同的背后其实是为了体验好，能让用户没有迁移成本。比如我们习惯了微信，当你借鉴微信的设计思路去做新产品时，大概率就会直接借鉴微信的设计，好让用户在打开新产品的时候有熟悉感。
+
+越是大众的产品，在体验层面的创新越难。因为所有的数据都会指向一个结果——保持老样子是最好的。就像《三体》说的，文明进化会被锁死，其实产品体验也会被锁死。
+
+真的创新是要改变用户习惯的，在改变后，还能让用户喜欢，如果能做到这样才是真正的创新。很期待有产品敢于去尝试这种创新。
+
+小结时刻
+
+2013年，阿里宣布All In 无线，此时玉伯加入支付宝前端技术部仅一年，就面临支付宝前端团队解体，大家都需要面临选择，大部分人转岗去做移动开发，一部分人去做创新产品，而对于支付宝 PC 业务，公司希望有人留下带队，当时玉伯作为 P8，他选择留了下来。那时他对前端价值产生了怀疑，现在回看那时候很多前端人在网上的发言，仍能看出大家的迷茫。
+
+2014年开始，集团提倡“大中台、小前台”，大量中后台业务开始增加，中后台的产品体验也越来越受重视，玉伯开始组建蚂蚁体验技术部，聚焦蚂蚁中后台业务，继续回归“老本行”，在体验方面做深做强。
+
+玉伯曾经在《我们是如何从前端技术进化到体验科技的？》的分享中讲到“前端技术再牛，都很难直接解决产品层的用户体验。对中后台产品来说，设计的价值也远远不止于让产品的颜值提升，设计的更多价值，在于深入到产品的业务逻辑里去，去帮助业务梳理产品信息架构与任务流程。用户体验是一个非常综合的事，需要各种专业人士在同一个产品上聚焦发力，一起共同努力才能真正提升产品体验。设计师在这个过程中很痛苦，很多中后台产品都是非常垂直领域的业务产品，中间件、ECS、ODPS 等一堆专业术语让设计师们痛苦不堪，幸运的是，我们扛了过来。”正是因为扛了过来，才有了Ant Design、AntV等产品。要将后端服务传递到终端用户，中间隔着前端、设计和产品，体验技术部就是连接后端服务和终端用户的桥梁。
+
+最后，也请你一起交流对体验的理解，你觉得今天的产品有哪些亮眼的体验设计呢？欢迎在评论区发表看法，我们下一讲见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/03终端技术：浅谈小程序与客户端的发展.md

@@ -0,0 +1,103 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            03 终端技术：浅谈小程序与客户端的发展
+                            因为玉伯在前端领域的名气，我们原本计划请教很多关于前端的问题，但玉伯表示他其实可以多聊聊小程序和客户端的内容，目前这也是他比较关注的话题。除了蚂蚁的前端团队，他目前也在带领小程序团队，因此这一节，来看看玉伯对小程序及客户端发展的一些看法吧。
+
+
+
+极客时间：很多媒体和工程师对一些技术名词的解读都不一样，包括不同企业的讲法也不太一样，比如终端、客户端、桌面端、跨端、大前端它们的概念，你是怎么理解的？蚂蚁的标准是什么？
+
+玉伯：确实业界有各种解释，蚂蚁这里，客户端比较清楚，客户端就是 iOS 加 Android，也可以叫移动端。有时候也会把 iPad 端也当成客户端，不过 iPad 端现在也不怎么提了，兼容一下就好了。这里有另外一个词叫做桌面端，桌面端目前更多指的是 PC 桌面端。
+
+终端就等于客户端 + 前端 + 小程序 + IoT 等等技术，有时间我们也会用大终端来称呼。终端其实英文名字有两个翻译，一个是比较挫的翻译 Terminal，比较复古。还有一个更好的翻译是 Device（设备），也就是设备端。PC 端就是 PC 设备端，手机端就是手机设备端，IoT 端就是 IoT 设备端。从硬件角度看，刚才说的 PC 端、手机端、IoT 端、iPad 端等，是各种设备端。
+
+从技术角度来看，我刚才说的终端技术主要等于客户端技术 + 前端技术 + 小程序技术，也包括 IoT 端的技术，以及 VR、AR 等技术。终端很多时候就简称端，在目前我们常说的语境里面，端就是终端。
+
+但遇到“端到端”这个概念大家一定要谨慎，谈到端到端的时候，一定要搞清楚是哪个端到哪个端。PC 端到手机端是一种端到端，但我们有时候说用户界面端到数据库这一端，或者接口端，也叫端到端。它的含义太泛了。因此当你听到“端到端”的时候，可能什么都没听到。
+
+大前端这个概念其实很好玩，经常会把前端团队和客户端团队放一起，然后叫大前端。还有一个词叫做泛前端，很多中小企业都是前端跟客户端在一个团队，这个团队就叫大前端团队或者泛前端团队。目前泛前端也不怎么提了，我个人也不太喜欢大前端这个词。蚂蚁这边，我们并不叫大前端，而是统一叫做终端，是前端加客户端一起融合成为了终端技术，是大终端的概念。
+
+前端还常提的一个词是前端工程化。工程化的本质就一句话：让一群人做好一堆事。前端工程化就是前端基础设施层，会提供一些工具和平台，然后让前端同学基于这些平台能更好地协同工作，这就是工程化。
+
+极客时间：现在你更多会关注小程序和客户端，你觉得客户端、小程序技术重要性在哪里？
+
+玉伯：回到蚂蚁侧，虽然前端本身的创新也还在继续，但真的要往前突破，做下一代技术的创新，这跟客户端、小程序、浏览器内核等技术是息息相关的。
+
+无论在 PC 时代还是移动时代，前端的代码都要有一个运行容器，在 PC 时代这个容器就是浏览器，那个时候的前端代码运行容器都是由国外公司提供的，比如 Chrome、IE、Firefox 全是国外的公司在掌握。然后发展到小程序这个阶段，变成我们逐步有机会提升更多可控性。
+
+小程序和客户端技术对于整个终端来说最大的价值点是它能拓展技术的大量可能性。国产化和自主可控是中国软件发展的一个重要方向。如果我们能够聚焦投入一些资源，基于开源项目，是有机会去做出一些关键基础技术的。
+
+极客时间：从产品和技术两个方面来说，你是怎么理解小程序的？从大家的视角看，它首先是一个产品。
+
+玉伯：目前业界谈的小程序，一般是指微信小程序和支付宝小程序。回到小程序的语境，小程序首先是块业务。比如说支付宝小程序，是基于支付宝小程序技术的生态开放业务。从技术视角看支付宝，支付宝的技术本质是一个 SaaS 服务平台，通过小程序这个载体，提供各种服务。
+
+支付宝上的数字生活服务非常丰富：水电燃气缴费、市民中心、线下支付、公共出行等等，有大量是三方的 ISV（独立软件服务商）提供的。这些服务在支付宝上的载体都是小程序，所以小程序首先是一块业务。
+
+也因为有小程序，支付宝才真正能做到生态开放。别人开发的小程序，能放在支付宝上跑，这就是支付宝的开放性。从技术视角看，小程序是生态开放的一个最好的技术和业务载体。目前中国是走在世界前沿的。这是小程序作为业务的理解。
+
+回到技术侧去理解小程序技术，要回到整个软件的发展史去看。上个世纪 90 年代很多软件是 C/S 架构，现在用的很多软件比如 Photoshop、Sketch、Office 这些都是 C/S 的。然后到了互联网时代，互联网的前十年开始用大量 B/S 架构，典型的比如淘宝， PC 互联网的时候并不需要装载一个淘宝的软件，你只要打开浏览器访问“taobao.com”就好，浏览器加服务端就能搞定。到移动互联网时代，B/S 架构又往前进化到移动 App，这时候淘宝购物大家也不去网站了，而是用手机淘宝。
+
+从 App 再往前演进是什么？在中国就是小程序。目前航母级的应用，无论是微信还是支付宝，其实都希望自己的 App 里还能够跑 App，App 里面跑的 App 就叫小程序。
+
+极客时间：国外在小程序这块的尝试你有关注么？
+
+玉伯：小程序在国外其实目前没有怎么起来，因为它缺少航母级的应用，Facebook 其实有机会，但是目前看起来也没有搞成。国外更多是走向 PWA（Progressive Web Apps，渐进式 WebApp），PWA比较适合海外的应用形态，没有我们做得这么极致，一定程度上微信和支付宝是走在世界前列的。
+
+但是小程序的下一代是什么？我自己的答案，真正的下一代可能是微应用。其实一个公司要开发一个小程序，再怎么节省成本，如果想要好用，还是得花费几十万甚至上百万的。是否能够把小程序的研发成本降低到你只要写一篇文档就可以了？这是有机会的，叫“Document as an App，文档即应用”，我们也在探索。像低代码的本质，也是降低软件研发成本。这些演进的核心都是为了降低成本，同时降低门槛，能让技术普惠。
+
+极客时间：所以现在做小程序开发还是很有前途的。
+
+玉伯：很有前途，也是趋势使然。我前面说了前端价值是降本增效，小程序技术本身的核心也是降本增效，它不光能够降低整个业务移动化或者业务应用化的成本，同时在数字化转型升级的浪潮里，也非常需要小程序。开发一个小程序和开发一个网站应用相比，小程序的成本能更低同时更方便。
+
+为什么要有小程序，要搞低代码，甚至无代码，很大程度上是因为整个软件化或者数字化的大趋势非常明显，在中国有大量中小企业都需要把业务线上化，但这过程中程序员又是有限的。中国的程序员加起来不到 1000 万，真的要做数字化，只用写代码的方式去实现的话，可能至少需要 5000 万甚至更多程序员。这几千万的差距，意味着需要通过一些方法一方面让大家快速上手，一方面继续降本增效。小程序的核心优势是便捷、快捷，我感觉小程序的数量只会越来越多。
+
+极客时间：现在大家再去做 App，是不是已经不是个很好的选择了，因为用户不太喜欢去装更多的 App。
+
+玉伯：这也是最近几年比较明显的趋势，一方面 App 数量会逐步收敛，但也要看行业，不少行业还是有做 App 的需求。比如说在金融行业，在蚂蚁有个产品还卖得挺好的，叫 mPaaS。mPaaS 就是一个移动开发平台。基于 mPaaS 可以快速开发一个独立的 App。我最开始知道这个东西居然卖得很好，我也挺惊讶的。
+
+但后来我发现确实还有好多金融机构、银行有很强的做自己独立 App 的需求，这涉及用户心智问题，App 可以给用户一种正规平台的感觉，给人安全感，比如转账操作在小程序很多人觉得不放心，毕竟大家对 App 的信任感也培养了好多年。除了金融行业之外，还有一个行业也对 App 有强需求，那就是偏工具性质的服务，如果做真正的工具，小程序的体验很难像一个独立的 App 做得那样好。
+
+刚刚说小程序可以降本增效，除此之外它还适合做用户增长，因为微信是一个海量的用户池，所以现在流行很多私域运营，微信的公众号、直播、视频号、朋友圈都是它的私域工具，都去微信薅用户，把用户圈过来之后，他们还是想往自己的平台上引流，把小程序作为增长工具。独立 App 依旧会长期存在，至少在未来 5-10 年依旧会有不少需求量。
+
+极客时间：当时咱们聊到阿里”All in 无线”的时候，有人选择转 iOS，有人选择去做创新产品，也有人留下。现在你可以说谁的选择更好吗？
+
+玉伯：很想说都一样，这样显得比较正确。认真来看，我觉得比较好的选择，还是坚持做前端的和去做产品的。当时转 iOS 的，从整体发展来看，后续不少同学遇到了一些瓶颈。接触过不少客户端同学，会发现客户端在当下对于职业的迷茫和困惑会比前端大多了。
+
+前几年蚂蚁这边有一批客户端转回前端，包括淘宝那边也是一样。这还是需求问题，目前前端需求量远大于客户端，而这个局面也是两个技术栈不同带来的。前端技术栈和客户端技术栈相比，最大的特点就是快和灵活。客户端写一个东西是很慢的，客户端的变更也很慢，但前端分分钟能给你做个页面出来。打个比方，目前支付宝这边客户端发版应该算快的，但再快也是周级别的，前端可以做到小时级别。
+
+互联网对速度的要求，以及对可控性灵活性的要求，使得前端技术栈在人机交互层比客户端更受欢迎，到现在为止这个趋势都还在演进。客户端更多下沉做容器、网络等基础技术。
+
+前端的快是研发效能快，但是客户端也有核心竞争力，就是性能快。目前会在对性能真正有要求的产品中才会采用客户端技术，比如支付宝首页，以及扫一扫、收付款、出行、卡包等核心模块，我们叫四大金刚。这四大金刚里，有很多动态化需求，也是用大前端技术栈去做的。
+
+快速灵活，这是一个很大的技术趋势。前端的灵活，印证了在前端圈很有名的一句话，“凡是能用 JavaScript 编写的应用，迟早都会用 JavaScript 编写”，从我入行以来到现在，这句话还在发挥作用。
+
+极客时间：现在客户端工程师遇到的困境也比较明显，你觉得现在这一批人应该往哪个方向去发展呢？
+
+玉伯：我目前看到的现状是，客户端有三拨人在往不同的方向发展。有一拨转向了前端，都是写代码的，其实让自己多一门技能，学前端去做业务，也是一个不错的选择，就跟阿里当时“无线 All in”的时候，很多前端转 iOS 一样。
+
+还有一拨人目前在做一些对性能要求很高的业务。比如说支付宝扫一扫，扫一扫如果用前端去做，体验永远不会有客户端做这么好的。所以这时候客户端好好地去做扫一扫的业务价值是很大的，挑战也很高。对性能要求很高的业务是客户端的第二条路。
+
+第三个方向，其实是往整个终端的基础技术走，比如做小程序的容器、下面的网络，做端智能、容器等方向，其实这块有很大发展空间，需要高精尖的人才不断去做深做厚。
+
+真正从技术深度，从纯粹狭义的技术角度来讲，客户端技术深度其实比前端要大。目前我们也在鼓励前端工程师，如果他还处于一个爱学习的阶段，那就应该去学客户端技术，这样他有更宏观的视野。
+
+极客时间：曾经你也说过前端的天花板低，现在你对所谓的天花板问题怎么看？无论是新人选工作方向，还是换工作方向，都会考虑五年、十年的发展前景，很多从技术转到业务的应该也会这么考虑。
+
+玉伯：有时候这是一种认知偏差，因为人是在变的啊。大家很多时候讨论天花板的话题，其实在讨论人的发展，不是讨论某个职业的发展。因为职业的发展要结合人来看，很多时候你是在假设一个人一辈子从事某一个职业，这肯定是非常少见的。
+
+之前大家一直说前端的天花板比后端低，谈到三年、五年甚至到十年的某个职业的发展速度，或者说哪个职业天花板更高，背后只有一个因素，是需求。供大于求就发展慢，供不应求就发展快。如果什么时候企业说不缺前端了，那就可以不做前端了。但是实际经验告诉我，从 2008 年，一直到目前为止，都是缺前端的。还没有哪个团队说前端会富裕。甚至之前我通过一些数据，能够判断公司哪块业务做得好。当某个业务嚷着叫着缺前端的时候，这块业务是很不错的。但当某个业务我给他推简历，他不要的时候，那这个业务可能增长遇到了点问题，或者它才刚起步。
+
+小结时刻
+
+小程序和客户端技术对于整个终端来说最大的价值点是拓展技术的可能性，小程序降本增效的价值、开放平台价值，以及与航母级应用的连接关系，使得投身做小程序的人越来越多，这也是需求使然。客户端技术下沉，对客户端工程师提出更高的要求，但目前 App 还是强需求。就像玉伯建议前端同学也要学习客户端知识一样，时刻把握技术风向，具备学习能力的人，才是能走得更远的人。
+
+另外，关于国内外小程序发展的话题，在极客时间曾有一篇文章也做过精彩的论述，在此推荐给你： Web开发：浏览器、小程序与PWA ，可以与本文结合，加深你的理解。
+
+最后，你所感受到的客户端趋势、前端趋势是什么样的呢？欢迎在评论区发表想法。我们下一讲见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/04开源三大收获：异步协同、文档优先与快乐工作.md

@@ -0,0 +1,81 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            04 开源三大收获：异步协同、文档优先与快乐工作
+                            希望玉伯能聊聊开源，因为他和团队折腾过 KISSY、SeaJS、Ant Design、AntV 等开源项目，KISSY、SeaJS 已经成为过去式，Ant Design、AntV 还在进程中。但说起对于开源的理解，对他触动最大的开源项目其实是 Yahoo 的 YUI3，玉伯也是在参与 YUI3 的过程中，体会开源带给他的快乐和反思。
+
+
+
+极客时间：你最早参与开源是什么时候，是以什么方式？你对开源最开始的理解是什么样的？
+
+玉伯：这就早了，我谈谈在阿里的时候吧。2008 年入职淘宝时就比较关注开源，当时前端有个标杆公司叫雅虎，雅虎是前端工程师的摇篮，有一批牛人。当年雅虎有一个产品叫 YUI，是前端最早的著名开源项目之一。
+
+淘宝最早用的组件库就是 YUI，当时我们基于 YUI2 在内部封装了一个版本叫 TBra，T 代表淘宝，淘宝前端的内部开源起步于 TBra 项目，代码写得很不错，我经常去看源码设计。
+
+最开始我对开源的理解，就是把源代码放出来，然后大家能够一起去看源代码长什么样子，是怎么实现的，还可以参与贡献，这是我对开源最初的理解。
+
+极客时间：在参与开源社区的过程中，从最开始开放自己的源代码，往后发展，越来越深入地去参与项目甚至主导项目，然后反馈社区，它是一个更进阶的过程。深入参与到社区里，你的状态是怎样的？
+
+玉伯：更进一步参与开源，是雅虎的 YUI3 项目，这是对我触动最大的开源项目。对我的触动点在于，当时 YUI3 的代码还没写多少，但是整个项目组就已经通过整个社区运作，共同探讨 YUI3 应该如何设计，比如应该分哪些组件，组件 API 应该怎样设计等等。设计先行，文档先行，而不是先写代码，这种开源协作，对我影响非常大。
+
+当时有一波国外前端大牛也在里面，我就看他们用英语在探讨，我当时的英语阅读和写作能力都突飞猛进。基本上天天都会去看，一有时间就会看，同时会用英语参与回复讨论。
+
+从参与文档讨论，后来逐步开始尝试去提交一些代码，YUI3 里面有些早期代码是我写的。这个过程很好玩，有点像打擂台。就是你提交了一个版本，对方一看这是什么啊，觉得你写得不好，然后别人会提交一版实现，把你的代码给覆盖掉了。这个时候，人的斗志就来啦，内心不服，就会想到更好的方案去实现，然后来个回马枪，把别人提交的代码再修改成自己的方案。
+
+我现在印象很深刻的一个组件，是 AutoComplete 组件，实现起来挺复杂的，当时对里面的性能优化点、渲染性能做了很多研究。我一直对性能优化感兴趣，跟这段经历也很有关系。这是我参与开源的第二个阶段，从看源代码，到参与讨论，再到开始打擂台的一样贡献代码，年轻气盛少年狂。这个过程，现在回想起来都挺开心的。
+
+那时候我天天盼着下班，我白天疯狂地在项目室闭关，就想尽快把业务代码的活干完，然后回到家里，快速吃个饭，就又开始疯狂地参与开源。印象中我每天晚上都干到凌晨两三点，很开心，很兴奋，好像不觉得累，睡眠质量也挺好的。
+
+对我而言，开源就是开心的源泉，现在回想起来都很开心。
+
+极客时间：你这种状态，当时坚持多久？
+
+玉伯：好久的。但后来发现熬夜对身体有影响，有时上午会没什么精神，而且因为凌晨几点了还在疯狂写代码，到了早上再继续写代码会有点疲。于是上午一般会选择去开会讨论或写文档，写文档时，脑海里已经在构思代码怎么写，怎么实现。吃完午饭精神就会好很多，中午打个盹后，下午会开始疯狂写业务代码。在我离开淘宝 UED 前，基本都是这种状态。
+
+极客时间：有没有一种可能是这样？那几年时间其实你写代码写太多了，已经在写代码这件事情上找不到更多的乐趣了，所以你更多地会去关注产品、业务管理？有这种可能性吗？
+
+玉伯：肯定有这种可能性，但代码本身依旧很有乐趣，但 YUI3 项目的缓慢进展，让当时的自己的确有些受挫。当年 YUI3 项目搞着搞着，我觉得项目有点看不到希望了，后来越发展越不太好，内心很受挫。YUI3 项目的发展不顺利，的确让我开始思考写代码是为了什么，为什么 YUI3 的代码明明这么优秀，但社区却好像越来越不喜欢 YUI3。这块的思考，让我将精力开始转向产品思考。YUI3 是一个技术产品，作为技术产品，真正决定产品成败的，并不是代码。
+
+写淘宝业务的前端代码时，更有体感，最终我发现淘宝的核心价值大都来自产品和运营，代码一定程度上只是实现工具。从代码实现，开始转向代码背后的技术产品设计，这是我参与开源的第三个阶段。
+
+小结起来，我参与开源有三个阶段。第一个阶段是看代码为主，第二个阶段开始参与文档讨论和核心代码实现，第三个阶段则是从产品视角去看开源项目。决定一个开源产品成败的，往往是这个产品本身的设计理念和思路是否符合潮流，如果方向不对，代码就很容易白写。
+
+代码是实现产品的工具，就像语言是沟通的工具一样。我们说话，本质上是沟通，语言只是沟通的一个工具。曾经有一段时间我很纠结自己有老家的口音，后来我一点都不纠结了，为什么？我发现其实在沟通这块，大家还是能够听懂稍微带点湖南口音的语言。我不会现阶段还纠结说我的语言要字正腔圆，反正大家能听懂。这是一种心态的变化。不是否定工具，而是于我而言，更看重用工具所做的事情本身。
+
+极客时间：从你参与 YUI3 项目对你影响这么大，加上你和团队一起折腾的 KISSY、SeaJS、Ant Design、AntV 等开源项目，你觉得参与开源对你产生了哪些影响？或者说收获，可以聊聊吗？
+
+玉伯：我第一个深度参与的开源项目是 YUI3，最大的收获有三点。一点是深度感受到了写代码是很快乐的。同时，还有一个更大的收获是，意识到代码是工具。第二点我很少对外说。
+
+很多时候人一定要知道自己拥有的所谓能力也好技能也好，究竟是有什么用？看开之后，人会坦然。比如我不会再纠结某个代码风格更好，我会更关注用技术能实现的产品价值点在哪。
+
+开源收获的第三点，是真正感受到了开源社区异步协同的美好体验，超级喜欢。做语雀跟这段经历也很有关系。有时会开玩笑说，给我们发旺旺、钉钉消息，我们回复会很慢，大家都不怎么想去看 IM 消息，但是给我们提一个 issue，我们立刻就会响应。异步协作文化，让我以及整个体验技术部都深受影响。
+
+除此之外还有一个收获就是理解文档的重要性，之前跟 YUI 项目那帮人聊的时候就是靠文档。文档跟微信聊天不一样，因为很多时候是跨时区的，每一次沟通都很珍贵，我们得把自己想说的话尽可能一次表达清楚。因此写文档的能力很关键，清晰表达才能做到几个回合之间达成一致，否则就是漫无目的地闲聊。还有比如你要去做某个功能，甚至你写了一堆代码要提交，你都得先写一堆注释，去告诉他我为什么要改你的代码，我改完之后究竟好在什么地方。在这些层面上是需要通过一些文档的方式来讲清楚的。文档先行的理念对我影响很大，我们做很多事情都养成了文档先行的习惯，这和亚马逊说的“六页纸”管理方法有异曲同工之妙。
+
+极客时间：在你自己后续的开源项目中，你怎么把前面学到的东西运用在项目上？
+
+玉伯：我尝试过，当时做 Ant Design 之前还有一个开源项目叫做 Arale（阿拉蕾），充分践行 YUI3 的那套理念，就是文档先行，我们对外说我们开源了，打开一看，一行代码都没开始写，充分践行文档先行。当时很多人在讨论，认可文档先行的占大多数。Ant Design 开源社区这块，好多人从早期就参与了，他们全程见证了整个过程。
+
+国内开源项目，一直有个我觉得不太好的做法，就是一定要等到代码写得差不多了才开源。很多时候怕自己代码写得太烂，一定要整到一定阶段，写到心目中最好了，才把代码放出来开源，但往往这时候别人都没有参与的机会了，对别人来说只能用。我一直觉得这种做法并不太好。
+
+我之前跟某开源负责人讨论过这个问题，我说他们开源目的不纯，他说我是古典开源主义。他们的说法我也认的。就像做产品有古典产品主义者，这批产品经理，一开始不会怎么考虑用户增长，而是关注我想不想做，我具体想做什么，然后根据自己的想法和设计把这个产品给做出来，给用户用，这叫做古典产品主义。开源也存在这种情况。古典开源主义是一种比较纯粹的状态，开源最早的理念就是分享想法，并不是分享代码。像 W3C（World Wide Web Consortium，万维网联盟） 最开始的标准诞生，就是我有一个想法，我希望能够召集一拨人来讨论，来实现。这是我接触的开源最原始的状态，也是我最喜欢的开源阶段。
+
+极客时间：最原始的开源你会去考古它的这些背景和发展，现在有没有什么好的资料可以来去看？
+
+玉伯：我接触过的最早是 Linux 开源社区。Linus Torvalds 本人挺有趣，他是开源的奇迹，对项目管控得非常好。社区里有很多观点，到目前为止都是很前沿的，比如什么是好的开源项目？我们很多时候会觉得要有影响力，觉得好的开源项目是目前还活跃的、还不断有人迭代的项目。但当时我看到过一个至今记忆深刻的观点：“死了的项目才是好的开源项目”。这句话是什么意思呢？就是说已经不再迭代的开源项目，说明它做完了，没有任何 Bug 了。Unix 里面很多底层小工具，做到删无可删了，做无可做了，Bug 也没了，不需要更新迭代了。这种东西才是最好的开源果实。
+
+这个概念延伸到产品领域，我曾经看张小龙讲微信的设计，其中讲到摇一摇这个产品，就跟 Linux 社区的理念是一脉相承的。微信摇一摇为什么可以做到不可超越，是因为已经把这个功能做到了极简化，删无可删，你只要加功能，你就输了。我觉得开源好多理念和产品也是很相像的，可以互相借鉴。
+
+小结时刻
+
+玉伯是开源圈里的古典开源主义，他说今天国内开源一直有一个不太好的形态——代码写得差不多了才开源。很多开源项目一定要代码写到最好了才开源，但对社区的参与者来说，别人没有参与的份了，这是不太好的。他怀念Ant Design开源的时候，有部分社区的人是全程见证它的成长的。
+
+《大教堂与集市》中讲“只要有足够多的 beta 测试者，几乎所有的问题都会很快呈现，自然会有人把它解决”，这种笃定和相信，今天是否还能大面积看到？“集市”精神就是社区精神，人的价值感、人与人的连接就在大大小小的社区里，开源社区就是一个庞大的意义共同体，而每个开源项目小组也是意义共同体，能够找到意义共同体的人无疑是幸福的。
+
+最后，也请你一起交流对开源的理解，以及你从参与开源过程中获得的养分吧。我们下一讲见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/05蚂蚁内部开源：迈出第一步，但还有很长路要走.md

@@ -0,0 +1,71 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            05 蚂蚁内部开源：迈出第一步，但还有很长路要走
+                            上一节玉伯分享了参与开源的故事与收获，开源精神和开源理念无论是在管理层面、产品层面都深深影响着他。除了 Open Source，我们也想让玉伯聊一聊对 Inner Source（内源）的看法。国内外许多大厂都在进行内源实践，蚂蚁也不例外。这一节玉伯主要分享了蚂蚁内源的发展，以及前端项目内部开源的经验。
+
+
+
+极客时间：我知道蚂蚁现在在做内部开源，企业做内源需要什么条件呢？蚂蚁现在大概做到什么程度了？
+
+玉伯：我可以先讲一下为什么会有内部开源。印象中 2019 年时，蚂蚁正式提出要做 Inner Source，Inner Source 的实践源自 Google 等硅谷公司。有时不少内部项目，因为各种原因，并不适合直接做 Open Source，然而公司已经足够大，比如说公司上万人甚至十几万人的时候，公司里其他团队可能也会依赖你这个项目，给你提需求，这个时候怎么办呢？从公司角度就希望你把代码开放出来，别人基于你的代码再去实现某个需求，这是内部开源的需求源头。
+
+再回到蚂蚁做内源的背景，当时集团已经开始“去中台”了（建中台的目标之一是去重复建设，当中台开始阻碍业务增速时，拆中台、去中台的声音开始出现），要求技术中台回归业务线。但是“去中台”也会带来一个隐患：回归业务线之后，如何保证不会又冒出一堆烟囱？这也是 Inner Source 应运而生的一个原因。
+
+如果我们在内部搞开源，哪怕技术回归到各个业务线，但是代码还是开放的，同时如果你的项目在这个领域是做得最好的，那其他团队就可以直接基于你的代码去做自定义，或者是大家在一起维护这个版本。所以在“去中台”大背景之下，Inner Source 是可以防止再次重复建设，或者至少可以减少很多重复建设。
+
+但时至今日，在软件界依旧会有一个观念叫做“Not Invented Here”，不是在我这里发明的我就不认，因为不是我亲手创造的，用起来我就觉得不放心或者不顺手，所以总想在自己的业务领域去发明轮子。这就是轮子满天飞的原因，不光是前端，后端轮子更多。
+
+前端老被吐槽轮子多，所以我们前端开源一开始就是以 Open Source 这种方式去做，但是后来因为公司变大了，各种内部的规章制度一管，加上中美关系的变化，就发现某些技术是要受保护的，所以导致很多技术其实并不适合做开源。所以回到前端做内源的真正原因，一开始也是一种无奈之举。
+
+当时刚好在蚂蚁做内源的人联系到我们，他们老觉得前端做开源是鼻祖，就会问我们的意见，我觉得内源确实挺适合我们的。很快我发现参与内源有个好处，Inner Source 真正用途是解决人性的问题，一定程度上能解决“Not Invented Here”的问题。
+
+比如说 AntV 数据可视化这个项目，最开始是我们团队去做的，很长时间也都是我们团队维护，所以很多人开始的观念就认为 AntV 是体验技术部的。Inner Source 来了以后，我们干了一件事情，让所有内源项目去团队化，让 AntV 变成是蚂蚁的，而不是体验技术部的。怎么做呢？首先把 AntV 贡献出来，变成蚂蚁的一个内源项目，类比一下就跟捐给 Apache 一样，捐给 Apache 之后项目就不属于自己公司了。内源就意味着 AntV 不再属于某个团队的，而是属于蚂蚁的，可以实现轮流维护。比如今年体验技术部维护，明年数金前端维护，后年蚂蚁国际的人来维护。通过这个做法希望解决“Not Invented Here”的问题。所以我们挺认可 Inner Source 的价值。
+
+但现在也看到一些问题，比如很多人不愿意进内源，或者进了内源之后还是强调项目是自己的，是有归属的，其他人是来做贡献的。这也可以理解，特别是在后端领域。我跟后端工程师们交流过，他们很难解决这个问题，一个原因是如果没有归属，就可能没人维护了，还有一个原因是别的团队没有这方面的专家，接不住这个项目。
+
+在前端这块，我们的做法是想一些办法让其他团队接得住，比如部门间人才的流通，把人才放到其他部门里，打破边界墙，这样在不同的团队都有人能参与及影响身边的人。AntV 和 Ant Design 目前算是部分实现了内源，是比较正面的案例，但像 Chair（基于 Node.js 的 Web 框架）很难内源出去，因为很少有团队能够接住，对方缺少这块专家。像这种情况，我们的做法是把一些模块、组件让其他团队承担，部分实现内源的目的。
+
+极客时间：整体来说蚂蚁内部开源推进得还算顺利吗？
+
+玉伯：谈不上顺利还是不顺利，蚂蚁内源还在路上。
+
+这是我自己的判断，我理解所谓顺不顺利，是看做内源这件事解决了什么问题，从一级到十级，我心里至少得到六级才行。目前蚂蚁 Inner Source 只达到了源码开放，内部社区还在构建过程中，Not Invented Here 涉及的人性问题更难解，这涉及技术人才的发展体系设计。
+
+极客时间：那未来要去做蚂蚁内源社区的规划，你认为要怎么去推进？
+
+玉伯：内源的蛮难的。回到开源的三个阶段，第一阶段是源码开放，第二个阶段是社区讨论，第三阶段是产品视角。内源很容易卡在第二步，因为第二步有很核心的点，是要有足够的人参与进来。对蚂蚁来说，能够达到第一步已经是个进步，至少代码开放了。
+
+极客时间：很多大公司都在推进内源建设，但把内源做成还是任重道远。关于开源，最后还想聊一聊商业化的问题，这两年对开源软件企业的投资也非常火热，你对开源商业化有什么理解？
+
+玉伯：开源商业化的话题我一直比较关注，但这个话题，我没什么见解。这是因为，前端领域的开源，目前更多在做社区。某种程度上讲，前端开源项目的商业价值很难很高，业界的很多前端开源项目，有商业化尝试的并不多，商业化非常成功的凤毛麟角。
+
+对蚂蚁前端的开源项目，我们受益于开源社区，我们的策略就是回馈社区，尽量不做商业化。
+
+像 Ant Design，我们的核心代码都是开源的，大家用就好。时不时也有中大企业会联系我们，表示想购买 Ant Design 的商业服务，想付钱买服务。但后来我们自己算了笔账，他们要的真正服务是基于特定业务场景的 Ant Design 的深度定制，去做适合特定业务域的一套前端 UI 的解决方案，这是一个专家咨询加资产定制服务。这个服务极耗人力，然而在国内，大多企业给不到我们的成本价，如果去做，做一个亏一个。真要做，我们得给 Ant Design 组建一个交付团队，然后卖人力、卖咨询、卖服务，然而这是一个没有规模效应的生意，有能力付费的企业并不多，最终会很亏钱，这条路很难走通。
+
+极客时间：所以如果要做开源商业化的话，基础软件还是更有竞争力。
+
+玉伯：最近几年开源商业化确实很火，很多 VC（风险投资机构） 知道我做开源也总是找我，我其实都想清楚了前端还是做免费。但跟他们聊的时候确实也了解到，目前在后端的数据库领域，包括数据界的 DevOps 领域，开源商业化是挺热的话题。
+
+很多做开源商业化的公司模式就是：开源就是商业本身。我开始也很好奇，这句话怎么理解呢？其实他们是分版本的，有一个开源版本来做影响力，另外的专业版本收费。
+
+开源本身可以增加用户买单的信任度，因为你有开源版本，又有专业版，别人可以看到开源版本的代码，它不是黑盒，用户会更有信任感。
+
+另外，通过开源可以抢占话语权，通过撬动一些生态的力量，然后一起去定义标准。通过开源可以博得业界声量，让业界开始认可而逐步成为事实标准，先开源就会抢占先机。
+
+有了信任感、影响力，以及获得制定标准的话语权之后，往往就能够圈一波自然粉，会有很多用户跟随，其实这也是私域运营，到最后一步才会做付费。
+
+这个模式能不能成功，这一波做开源商业化的能不能起来？还要再观察，因为 VC 的钱也刚进来，最终要看买单的客户有多少，是否能够支撑开源商业化的公司可以持续往前走。
+
+小结时刻
+
+蚂蚁做内源的原因之一是在“去中台”大背景之下，InnerSource 可以减少很多重复建设，尽量减少轮子满天飞的问题，同时前端团队参与内源开始也是因为一些项目不适合做 Open Source。蚂蚁内源现在做到源码开放也是迈出重要一步，只是离玉伯心目中的理想还有很长的距离。
+
+你对内源有什么理解，是否从内源项目的参与过程中得到收获呢？欢迎在评论区发表想法。我们下一讲见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/06从淘宝到支付宝：几次项目失利，但创新产品之心未死.md

@@ -0,0 +1,126 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            06 从淘宝到支付宝：几次项目失利，但创新产品之心未死
+                            玉伯在淘宝曾经参与内部赛马，搞了几个月产品后惨败，失败后回淘宝技术部到 Java 团队做前端工程和性能优化。除了继续搞技术，玉伯其实还在“偷偷”搞产品，我们请玉伯讲了讲他和当年那些失败的创新产品的故事。-
+
+
+极客时间：参与内部赛马是一个什么样的故事？你参加了什么样的创业项目？
+
+玉伯：2010 年左右，淘宝为了鼓励内部创新，发起了一个创新孵化项目，叫做淘宝赛马。你想做某个事情，就可以去立项并召集感兴趣的同学参与，组队成功后一起去做。
+
+我当时加入了一个赛马项目。当年阿里依旧有一个社交梦，我们那个赛马项目就是在往社交方向做一些探索。干了几个月后，发现有点干不下去了。这段经历对我来说，一方面负责前端，但更多是参与产品讨论，整个过程挺折腾。
+
+最后项目失败了。早期产品讨论阶段，大家就已经出现分歧。很多人都在表达想法，第一版 PRD 就花了一个多月，等到做开发时，人心已经有点不齐。代码最终需要我们来写，然而作为程序员的我们自己内心并不认，就不太想写，很犟。觉得我们是来创业的，一定不能这么妥协。最终我选择了主动离开。
+
+参与赛马那时，真的是年轻气盛，就是不妥协，就拜拜了。那个产品真的是没有想清楚，社交领域非常大，熟人社交，还是陌生人社交，还是某个特定领域的社交，和竞品的差异化竞争优势是什么，第一批种子用户在哪，如何运营等等，都没怎么讨论清楚。选择了果断退出，现在想起来是一种勇气和幸运。
+
+有一个细节印象深刻。赛马项目启动时，我们每个人写了一个心愿，塞到一个信封里封起来，说等成功时再拆开来看。现在回想起来，再也没机会拆开了。
+
+这是我参与赛马的一段经历。
+
+极客时间：那个时候这种赛马的项目成功率高么？参与这个赛马项目你最大的收获是什么？
+
+玉伯：赛马并行启动的项目，我记得有六七个，最终算成功有两三个，准确数据我不太清楚。
+
+对我来讲，这段经历最大的收获是，发现做产品原来这么难。之前我做前端开发，是在支撑产品经理做产品，经常会觉得产品经理提的需求不太靠谱。在赛马之后，自己对产品经理的心态有了很大的变化，觉得产品经理真心不容易。
+
+赛马失败后，我回归了淘宝技术部的 Java 团队，一边继续做性能优化等技术方向，一边更心痒痒想去做产品。赛马的失败，让我意识到产品经理的不容易，内心里反而更想去做产品，产品心在不断生根发芽。
+
+极客时间：从 UED 到赛马，那就相当于你从 UED 离开了，到一个小创业团队里面去，成功或失败也并不知道，是一个冒险的选择。你除了在 Java 团队搞性能优化的事情，还在做产品，具体是什么类型的产品？
+
+玉伯：回到 Java 团队后，一方面做技术，同时有在尝试做一些业务型创新产品。
+
+其中有一个创新产品，是想做“中国版的 Pinterest”，Pinterest 在国外当年很火。我在淘宝 UED 的经历，让我对设计包括基于图片的兴趣社交很感兴趣。其实从淘宝 UED 出来之后，我可能一直就没有怎么安分过，看起来在做技术，实际上在搞各种产品。
+
+中国版 Pinterest 这个项目不算失败，项目成员里有产品经理、设计师还有后端开发，我当时是半个产品经理加前端的定位。后来除了我和一个设计师之外，项目组里其他同学都选择出去创业了。当年国外有个很有名的投资人，投过 Pinterest，他来中国在看类似的项目。看的过程中发现我们在做这块，同时杭州还有个公司也在做这一块。最终这个投资人选择投我们，这是出去创业的兄弟们的信心来源之一。图片兴趣社交在中国很难做，特别是朋友圈起来后。最后这个项目有转型到一个特定领域，杭州那家公司，发展成为了花瓣网。
+
+极客时间：在淘宝做了这么多项目，各种折腾过后，你觉得你沉淀和收获了什么？
+
+玉伯：我觉得收获的东西有三个点。第一点是，那段经历真正让我开始想清楚自己对什么感兴趣，这是蛮有意思的。比如从中科院物理所退学，是让我想清楚我原来对物理科研不感兴趣，发现编程能给到自己更多快乐。后来参与赛马包括折腾各种创新产品，我的收获是，意识到技术不是万能的，技术只是工具，技术是产品的实现手段。
+
+很多时候大家谈技术深度广度，我都觉得这有什么可聊的。真正的技术深度可能在什么地方？在学术界，在各种科研实验室。而在大厂里，所谓的技术深度往往只是工程成熟度，真正的有深度的技术创新凤毛麟角。在大厂里，技术更多是为产品和为运营服务的。很多时候，一个产品成功了，背后的技术就被说得很牛，然而很牛的产品，往往并不代表用到的技术就很牛，两者有交集，但并不多。
+
+还有第二个收获，在当时可能自己已经有了初步的团队意识，开始知道很多事情单枪匹马是干不成的，需要有团队才有机会去把一些事情做得更长远或者更有可能性。
+
+最后一个收获，是自己心态上的收获。经过这些折腾后，每次看到希望又跌下来，再次看到希望又跌下来，像过山车一样，这让自己遇事时变得比较冷静。现在面对一些折腾或者困难时，不会有太大的情绪起伏，就觉得都没啥，反正都经历过，会有一种看淡的感觉在内心里。
+
+极客时间：图片社交产品最终没有做成，其他人选择出去创业，你来到了支付宝，开始另外一段旅程了。也是在企业服务开始被更多关注的时候，在支付宝建立起体验技术部，为中后台业务做支撑。但在建立体验技术部之前其实还经历了阿里“All In 无线”，前端面临价值危机的时期，在你早期的发言里也看出那时候的迷茫。在支付宝你感知到的这种趋势变化是怎样的？
+
+玉伯：到支付宝也是机缘巧合，因为之前的项目都失败了，当时我的 Leader 是范禹，范禹想留我，但是也很难找到一些重要的事情给我做。当时范禹相当于是淘宝首席架构师，鲁肃是支付宝的首席架构师，他们中间有些内部交流和沟通。这过程中，我偶然接触到鲁肃，发现鲁肃挺有意思的，鲁肃又一次分享里，居然反复提到了两次前端。于是我就找鲁肃聊了聊，然后联系上了支付宝前端团队，就来支付宝了。2012 年 2 月左右到了支付宝，一直到现在。
+
+在支付宝就是老老实实做技术，确实因为之前各种折腾会使得自己在产品这一块有点灰心，之前做产品来回折腾了三四次，感觉做产品好难。转岗到支付宝后，心态很简单，就是好好做技术，同时开始在思考支付宝前端怎么往前走一步等问题。
+
+2012 年干得挺欢，跟很多同学一起做开源，做整体架构，当时所在大团队 40 几人，我带了一个六七人的基础架构组，天天讨论问题，天天写代码，挺开心的。
+
+到 2013 年后，开始要“All In 无线”，当时自己很懵，不知道何去何从。
+
+后来整个前端分成三波，第一波是响应公司号召，去转 iOS 了，因为无线 All In 了，前端写 PC 没前途了，这时候转 iOS、安卓才更有前途，而且对公司来说也会更好，所以就有一波人转客户端。
+
+还有一波，我当时的主管是么么茶（吴振昊，钉钉联合创始人），他先去做来往，后来去钉钉，现在是钉钉的产品总监，他号召了一些人去投身创新业务。理论上按照我的过往，我应该是极大概率跟着么么茶去做来往。但因为赛马的经历，让我很长时间对产品有点提不起兴趣。
+
+剩下十几个人包括我，就是第三波，是被剩下的。当时支付宝收银台还有很多 PC 业务，这块无论怎么调，总得有人留下来去做既有的 PC 业务，我当时觉得 PC Web 开发也挺好，就选择了留下来。
+
+面对这些变化，我也动过想法，当时第一反应是想转 iOS，当时也在学 iOS。只是后来觉得团队这么一弄，PC 实在没人，总得有人留守。同时因为我那时是 P8 层级，只剩下我这一个 P8，鲁肃也找我希望我更有担当。纠结过后，最后选择了留下来。
+
+当时阿里无线 All In，对于前端来说打击很大，我印象中很多人开始怀疑前端的价值。我在 GitHub 上也写了很多文章，写了很多关于前端的价值、前端的低谷、前端如何发展的文章。当时自己也是通过文章在梳理自己的思路，现在回看，是一段难得的经历。
+
+极客时间：你感受到前端价值的再次显现，是因为后来的蚂蚁金融云项目吗？
+
+玉伯：金融云是一个金融级的 PaaS 平台，底层基于阿里云，上层满足很多银行和金融机构的上云需求。蚂蚁是专业做支付和金融的，我们在云上基础设施上的经验，有机会让银行和机构复用，这是金融云的大背景。
+
+云服务就意味着当年有大量的中后台开发，因为所有的云服务它从前端的角度来看都是SaaS，最终都要有人机交互界面。这些交互界面的载体就是SaaS产品，而且在蚂蚁内部也有大量SaaS产品，有很多中后台系统。加上我们要对外做金融云，所以当年有大量企业级需求，非常缺人。
+
+前端往移动的转型，我的感知是到2016年达到峰值，从2013年到2016年，大家没想到时间竟然这么短，三四年就到峰值了，之前我的预测至少要5-10年。2016起，云服务开始逐步起来，中后台业务需求快速增长，需求的增长已经大于我们团队能承载的量，不光是缺前端，后端、产品、设计等人才都缺。
+
+那时候我向鲁肃汇报，鲁肃给我的要求很简单，就是蚂蚁的前端出问题就找我。大家经常会说阿里 KPI 怎么样，我一直没什么体感，我很多年 KPI 就是鲁肃这么一句话，更多是自己给自己定方向。鲁肃提的要求挺好：如何做好蚂蚁的前端基础设施，蚂蚁前端出问题时，团队如何第一时间能解决。这些是一些基本要求，这些基本要求，就已经可以做很长时间。
+
+我当时本职工作是解决前端的问题，同时 2014 年开始组建 UED 团队，服务于金融云等企业级业务，前端团队和 UED 整合在一起，通过技术和设计，共同服务于用户体验，这也是大团队命名为“体验技术部”的初心。
+
+极客时间：以前的中后台业务，你觉得它的体验做得不好，具体是体现在哪些方面？
+
+玉伯：技术平台的产品经理，往往是技术同学在兼任，技术人做产品，往往会有很多坑。比如，抽象能力对产品经理来说是很关键的一个能力，然而，一个技术人去做产品，有时候会过于抽象，技术同学以为自己能理解用户就能理解，其实不是的，用户可能搞不清楚你为什么这么抽象，这是第一个坑，很容易踩到。
+
+第二个常见的坑是，技术人的潜意识会有“技术万能化”，感觉没什么搞不定的，整个思维模式并不是用户视角，而是用很技术范的视角在看问题。这个坑，使得早期很多技术平台产品，做着做着就变成了功能堆积，在用户动线、产品体验地图、用户故事很多地方都说不清楚。技术人很容易缺失基于用户视角的产品设计思维，以为按照技术的方式把功能堆上去就好了，这使得很多 PaaS 产品的体验都比较糟糕。
+
+极客时间：那时候是没有专门的产品经理角色么？
+
+玉伯：我印象中有那么一两个，但也是技术转的，并不是专业的产品经理。开始招产品，是从做金融云业务开始。到现在已经好太多，现在产品经理已经有百来人。之前中后台业务也没有设计师，都是前端在做，我后来从零到一组建了一支 UED 团队，有个设计师参与后，中后台的整个体验有了量级的体验。
+
+极客时间：从这个节点搭团队，你是从零开始招的这些人，当时会有什么样的岗位模型么，怎么想清楚都要招什么样的人？
+
+玉伯：当时没怎么去定义岗位模型，更多是用情怀以及企业级设计的价值，去找感兴趣的人。当时搭团队，有个机缘巧合，“无线 All In”三四年发现到顶了，这时候有一批人才外溢，比如当时来往搞失败了，我就去找来往的设计师。创新项目搞失败了我自己经历过，就会跟他们说，要不回支付宝吧，以感同身受的方式去吸引了一些早期设计师进来。中间也踩过很多坑，因为一开始招聘设计师，我自己的专业度不够，又迫于业务需求，急于把团队组建起来，可以说有点饥不择食，这给团队往后发展带来了一些隐患。
+
+从 2015 年到 2017 年发生了很多事情，过程中挺好玩的。一旦有了 UED 后，加上前端团队，他们之间就会开始产生化学反应。后来我们能做 Ant Design，跟设计师与前端工程师的化学反应息息相关。Ant Design 的基础是设计理念，在蚂蚁能从体验技术部诞生出来，这是融合带来的特色，不同工种有不同的思维模式，有时真的要放在一起，物理上放在一起，天天在一起碰撞，才有机会做出一些有创新的有特色的事情出来。
+
+设计师经常会有很多想法，但是要去影响到业务，还是很难的。来了体验技术部，这边不缺程序员，缺设计师，刚好互补。提升用户体验，跟前端的实现息息相关，跟设计师的设计也息息相关。两者一拍即合，很自然就产生了化学反应。
+
+极客时间：让这两个团队融合，你有做一些努力吗？
+
+玉伯：做了蛮多事情。比如，哪怕业务方给我的压力很大，我当时还是给 Ant Design 做了立项，作为一个正式项目去做，确定这个项目谁是前端负责人（偏右，网名 afc163），谁是设计负责人（他山，外号叫勺子），给团队信心是蛮重要的，虽然真正全职投入的也就三四个人。
+
+当时我们还花了大量精力去研究竞品，会发现竞品也没那么强，有些地方也乱糟糟的。我们去做组件库，并不是一个超前的东西，后来发现组件库的底层是设计语言，就很兴奋，觉得有搞头。虽然现在设计语言的提法已经满大街，但当年谈这个概念的并不多，Ant Design 提设计语言，在当年是有引领性的。
+
+还有一点就是开源，我们是以开源的方式去做 Ant Design，对很多程序员非常有吸引力，会觉得做开源能让自己很有成长感和成就感。
+
+做 Ant Design 这件事，也源自我自己的信心。信心来源于早期做开源时的经历，之前在淘宝的时候做过淘宝的 UI 组件库，只不过当时没有设计语言，纯粹是一套前端组件库，但一定基础上对于业界处于什么情况，我们机会在什么地方，我内心比较笃定，心里已经有了七八成把握。确定 Ant Design 要做后，会一直强调长期主义，要有三五年的长期坚持，才有可能做出一点成绩。很幸运，我们坚持住了。
+
+极客时间：感觉在体验技术部，你给这个团队找了很多目标，很多方向，做了很多产品。这是你提前规划的体验技术部的目标吗？你当时希望把这个团队打造成什么样呢？
+
+玉伯：当时团队最主要的职责是支持业务。业务在快速增长，支撑业务需要人员，团队如何组建起来，如何快速招聘到位，这是我有几年的关键目标。组建团队过程中，我需要一些事情去吸引人才，比如做 Ant Design 其中一个目的也是吸引人才，而且它确实起到了这个作用，实现了正循环。有人坚持做开源，开源开始做出一些影响力，从而进一步吸引更多人加入。现在 Ant Design 开源社区日常贡献活跃的有几十人，已远超开始投入的三四个人。
+
+Ant Design、AntV 是外界比较了解的两个产品，还有一块是投入Node.js，把我认识的大拿苏千从淘宝挖过来了，然后放心地交给苏千负责。当时的主要布局，是在设计语言、数据可视化、Node.js，还有前端工程化这四个领域，有认真去规划和召集人才，然后坚持长期去做。
+
+小结时刻
+
+和印象中的前端大牛不同，从淘宝到支付宝，玉伯其实一直都在尝试做产品，一直有一颗产品心。到支付宝建立体验技术部后，有更多的前端人、设计师在成长为产品工程师。为了吸引人才，玉伯画了几张“饼”，Ant Design、Ant V都是吸引人才的饼，因为创新产品的从 0 到 1，并不是大张旗鼓地开干，前期更多是这些人在支持业务的同时兼职做这些事。
+
+关于体验技术部的故事，现在在网上还可以找到“那些年的体验技术部”系列文章，记录了从这个部门孵化出的产品和成长起来的人的故事，如果你对这个团队感兴趣可自行了解。
+
+下一讲，我们聊聊玉伯操刀的一个工具型产品——语雀。感谢你看到这，我们下一讲见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/07产品故事：语雀两度生死局.md

@@ -0,0 +1,93 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            07 产品故事：语雀两度生死局
+                            语雀是一款文档和知识库产品，2016 年从一个技术团队支付宝体验技术部生长出来，2021 年蚂蚁成立了智能协同事业部，重点产品即为语雀，以独立 BU 运作，算是完成了“成人礼”。我们和玉伯聊了聊语雀的成长故事。
+
+
+
+极客时间：市面上有很多的文档类产品，语雀的口碑还不错，它能够在蚂蚁立足，特别是在阿里有钉钉文档的情况下，外界对二者的比较一直都在。我知道当时阿里准备做钉钉文档的时候，直接分了语雀的一批人去钉钉，对语雀来说应该是比较艰难的时刻。那么从开始一直到现在，你觉得语雀面临过哪些生死时刻？
+
+玉伯：我分享几个时间点。2016 年，体验技术部有个创新产品孵化机制，叫策马扬鞭，语雀是参与策马扬鞭的项目之一。那时语雀还叫云雀，英文名叫 lark，是一款为金融云服务的文档产品，出发点是“让技术人写文档更简单”。
+
+语雀的发展可分成三个阶段，2016 年到 2018 年是语雀孵化期，怀胎两年，我们从文档这个需求起步，开始逐步替换掉公司里的 Confluence 和 Wiki（企业知识库软件）。我们实现了一个 Markdown 编辑器，程序员特别喜欢，语雀就在程序员团队开始流行。2016 年从零起步，到 2018 年在阿里内部语雀的 DAU（日活）已经破万，意味着每天有一万多人在使用内网语雀。10000 DAU 是决定这个产品能孵化出来的重要节点，在阿里内网，很多产品的使用人数都有天花板，过 1000 DAU 都挺难的，语雀能达到 10000 DAU，代表着无论是老板还是同学都会有基本感知。在我们团队内部，语雀也是一个内部创业项目的典范，这是语雀从零到一孵化出来的第一阶段。
+
+第二个阶段，从 2018 年 1 月 8 号开始，我们有了 yuque.com 服务，正式对公网提供服务。现在我们会把 2018 年 1 月 8 号定义成语雀的生日，一方面是有了正式对外服务，一方面是因为这次发布会上，才把名称从云雀改名为语雀，同时也是因为到 2018 年，才算正式成立了一个团队去做。之前都是孵化期。
+
+在国内，2018 年可以称之为文档爆发年。腾讯文档、钉钉文档、飞书文档等，我印象中都是这个时期开始出现在公众视野。语雀也不断加大投入，从七八个人，都 2018 年 7 月份时，团队已扩展到三十几人，可以撸起袖子好好干一场了。
+
+在2018 年 7 月份时，语雀很快迎来了第一个生死点，各种文档都在起来，阿里也想做文档。公司在整体盘完后，确定要做阿里文档，同时最终决定要在钉钉做。那这个文档的初始团队怎么来？最后就是从语雀团队中分一拨人过去。语雀最终把三分之二的人，输送给了钉钉，成为了钉钉文档的初始团队。
+
+这下语雀只剩下七八个人，团队非常灰心，但同时大家又很有信念，非常笃定。于是开始重新招聘，到 2019 年 4 月左右，团队重新回到二十几人，公网语雀也开始有了初步商业化的能力。2019 年 4 月 15 日是语雀商业化的开始时间，语雀算是又活了过来。
+
+极客时间：大家觉得语雀可能要死掉，会不会有一个原因就是公司对做文档这个事情很重视，希望集中资源只做一个最好的。
+
+玉伯：这是很重要的原因。另外，之所以还能留下语雀这个团队，而不是全部整合到钉钉文档，是因为语雀想做的，并不是纯文档。当时我会不断讲语雀是什么、钉钉文档是什么，这两个东西是有区别的。并打比方说，阿里文档是做 Google Docs，语雀是做 Confluence，这个类似，让很多决策者开始懂得钉钉文档是钉钉文档，语雀是语雀，这两者有交集，但更大的是差异，两者产品定位是不一样的。还有一个关键点是，语雀在内网已经有很多用户量，内部不可能直接关停，现有客户需要继续服务，再怎么说也得留下几个人来维护，所以最后才留下几个人。
+
+另外还得感谢无招（陈航，原钉钉负责人）。说实在的，我觉得无招一定程度上是语雀的贵人，我能留下语雀的火苗，一方面我觉得产品定位不一样，一方面是现有客户要继续服务，同时，无招的一个观点也非常关键，无招觉得钉钉也是从无到有、好不容易创新出来的，语雀也是，所以对创新产品，公司应该要更有耐心，不能一下把语雀给掐死。其实他本来可以把语雀团队全部拿过去。就因为这句话，后来我跟他一直关系不错，彼此会敬佩。
+
+到 2020 年时，语雀又迎来一次生死局。因为当时钉钉文档搞了很久，效果没达到预期，当时阿里云还是想尽快把文档方向发展起来，因此希望把语雀、钉钉文档、阿里云笔记等集团内各种做文档的团队聚集起来，成立一个独立的阿里文档事业部，想让我去带，不放在钉钉。这时，无招急了。
+
+对无招来说，文档是钉钉很重要的一部分，独立发展文档并不妥当，这使得集结起来做阿里文档的事情又黄了。我说无招是语雀的贵人，也在这件事情上。无招不同意做阿里文档的思路，其实是间接又帮了语雀一次，让语雀能继续做。否则去搞阿里文档，语雀团队可能就又没了。
+
+这个过程中，语雀算是经历了两次生死劫。后来一直到 2021 年 6 月份，正式成立了智能协同事业部，这个事业部的核心产品就是语雀，以一个独立 BU 去运作，语雀才算变成了公司的一块业务，正式比较稳定地能组织化去做。
+
+在 2021 年之前，整个语雀团队都一直有个身份焦虑，虽然我们不用考虑下个月的工资从哪里来，但时时刻刻都得考虑语雀跟公司是什么关系。我们经常被人问起的就是“语雀和蚂蚁是什么关系？”，你又不是做支付，又不是做金融的，你在蚂蚁好奇怪啊。2019 年前后会天天被人问，我们自己也会这么想，会想公司什么时候会不让我们做了，会有这种担心。一直到去年，才不担心。
+
+极客时间：你说钉钉和语雀这两个产品其实定位是不一样的，但从开始语雀也是做文档的，知识库这个概念，是一开始就想好的吗？
+
+玉伯：2016 年确实是文档，当时我们是借鉴了石墨文档，而且第一版在内部长得都像石墨，后来我们觉得石墨文档架构有问题，2017 年我们把整体架构推翻重来了。2017 年更多学习的是 GitHub，语雀其实就是文档界的 GitHub，GitHub 的核心是代码仓库，那么对应的文档仓库是什么？就是知识库，在语雀建一个文档的话你要先建知识库，从 2017 年我们就以知识库去定位语雀。
+
+极客时间：知识库这个概念是怎么来的？是你命名的么？这个名字对于用户来说是有一个熟悉过程的，比如说我最开始看到知识库这三个字的时候不知道是什么意思。
+
+玉伯：应该说语雀在文档产品里面正式把这个概念给推成了，我们一开始也不叫知识库，我们一开始叫仓库，因为我们最早是学 GitHub，代码仓库，我们是知识仓库，但是知识仓库这个名字对普通用户不太清晰易懂，于是我们觉得还是叫知识库比较好。
+
+现在知识库这个概念钉钉文档和飞书文档都在用了，他们之前都不叫知识库，钉钉之前叫知识空间，里面有知识页、知识集等概念，后来才改成知识库这个概念。知识库这个概念还跟业界一个概念——智库是有相似性，语雀把这个概念变成了大家当下的理解，后来发现飞书他们也开始这么叫。
+
+极客时间：再聊一聊语雀的定位和在一些事情的取舍，回到最开始做语雀的需求是想替代 Confluence 和 Wiki，在阿里内部大家用了这两个系统体验很不好是么？
+
+玉伯：对。因为当时阿里每个大点团队几乎都有自己的一套 Wiki 或者 Confluence，但实质上是彼此不互通的，都是各自搭一套。支付宝还好一点，整个技术部只有一套。同时 Confluence 有一个问题，它很容易知识僵化。在国外 Confluence 有很大市场，而且市场利润各方面都是挺好的，我觉得它在外海服务于一些中大企业是挺不错的。
+
+但在阿里，大家可能都听过一个词叫拥抱变化，变化很快就意味着你用 Confluence 好不容易把目录树、各种结构都搭好了，然而组织结构一变化，Confluence 的文档就很容易变成一个荒岛，然后又要重新去搭建，很麻烦。很多时候，知识沉淀是跟组织结构有很大关系，当组织频繁变动时，当产品更新迭代很快时，需要的是一种更灵活的组织方式。在知识库领域，语雀切的是更灵活的结构化组织这个点。我们没有像 Confluence 一样去做很大的一个目录树，还是回到头来做非常离散的偏小团队的方式，同时借鉴了 Wiki 词条的组织方式，让文档之间都是平等的，文档树则通过目录编排去实现。这样在组织变化时，迁移成本会比 Confluence 会低很多，会比 Confluence 更适合组织的频繁变化。这个点，是语雀能在内部流行起来的重要因素之一。
+
+当然还有一个原因，就是我们有很好用的 Markdown 编辑器，程序员特别喜欢，这也是一个很大原因。基本上早期就是靠这两个核心产品特色在阿里内部立住脚。
+
+极客时间：你之前还说过，集团曾经对语雀也提过一些需求，但很多你们都没有做，大概是什么类型的需求，你们是怎么判断做还是不做的？
+
+玉伯：对，这个有好多。最典型的需求就是很多团队都希望有个知识门户，团队可以做整体管控，自己团队里的同学写的各种文档能够汇集到这个团队门户中。还有一些个性化的需求，比如希望当发布一个新人指南或者业务关键文档的时候，相关人员能看到且可以签到或者学习打卡等，这类需求偏学习平台性质。那语雀的做法是，宁可开放 API，让大家自己去基于语雀的 Open API 去定制包装，而不是我们去实现。因为每个团队的管理方式和所处的阶段不一样，这使得各种管控需求也往往会不一样，比如高德的需求，和菜鸟的需求就有比较大的差异性，菜鸟的需求，和阿里云的需求，往往甚至会彼此矛盾，每个大团队内部的知识管理体系不同，只有需求方自己最懂自己的需求，基于开放去自己定制，往往会更好，语雀去做，很容易极耗精力，最终用户可能还不满意。
+
+极客时间：像这种需求的思考是最开始就已经非常清晰了，还是说开始的认识也有一些模糊的地方？
+
+玉伯：肯定一开始是模糊的，很容易被绑架，因为总拿客户第一说事，还会有来自某些高管的压力。我们早期也没看透，做过一些这种需求，后来发现基本全是坑。现在逐步看清楚之后，会非常谨慎。
+
+极客时间：2019 年开始语雀尝试商业化，你也说语雀在商业模式上也算走过一些弯路，比如服务超过 1000 人的组织可能就涉及到定制，在做过这方面的尝试后，你们最终能确定就在企业服务中做真正的 SaaS 产品。能坚持这个目标也是很不容易的，因为现在很多所谓做 SaaS 的企业，有一个困扰是，因为业绩压力，就可能耐不住性子去做标品了，因为标品价格低嘛。这个时候如果有客户光顾，为了业绩他可能就会给客户去做定制，因为这样客单价高，企业就会很难去 hold 住这个立场。
+
+玉伯：这个其实就是我没有选择出去创业的原因。对创业我也有自己的想法，创业其实很多时候可分成两种思路。第一种创业思路，就是为了钱或者是为了创业而创业，大家希望出去干一番事情，达到一定的规模，拿到 VC 的融资，最后还能够去敲个钟上市。很多人创业都是被这个故事给绑架了。我觉得这种创业，可以形容为“跳悬崖”，做很多事的出发点都是为了什么来钱快去做什么，因为这样才能保证在摔死之前能找到起飞点。这很残酷，很多这种奔着上市去的创业或者奔着资本去的创业，就是在玩九死一生的游戏。我觉得最后能成的都挺厉害的，成功之后就可以开始讲故事了，市面上充满着这种故事。
+
+我自己的创业核心，还是回到“业”本身，“业”是佛学里面的一个概念。佛学里面叫做业障、业力，这个“业”就是你把自己内心想做的事情做完，同时你想做的事情也能帮到别人，这就是业。“创”是什么东西？就是创造，就是把业完成的过程。所以我内心的创业就变成：我想去做这件事情，且这件事情也能够帮助别人，那就去做。把这个定义好之后，除了前面那种出去开公司、去上市之外，对我来说，可选择的创业方式就太多了。
+
+比如留在一个公司里，成为一个技术专家，通过大公司的平台去做自己想做的事情，这也是创业，就像当初我通过淘宝去服务更多人。我做语雀也是一样的，我想去做一款文档和知识库工具，希望更多人基于语雀能开始生产创作，让自己和让他人都能受益，这是我内心想去实现的一个“业”。
+
+在这个选择过程里，也会有纠结，我有过很多选择，比如听 VC 的建议去拿几千万投资出去干，或者继续在大公司干。在大公司里干也会有很多选择，比如选择在阿里干，还是在腾讯干，还是去金山或者去字节，存在各种选择。
+
+但最终我发现面对这些选择时，我只需回答一个问题：究竟哪个选择，可以把我想创的“业”更好做出来，也就是成功的概率更高，那我就去做哪个选择。如果出去开公司能够更让我更容易把“业”创出来，那我就去开公司。但是我自己分析下来，目前留在蚂蚁做，成功的概率反而是最高的。
+
+极客时间：在大厂内部创业和出去创业相比，内部创业可能需要扛的压力小一点。
+
+玉伯：焦虑的事情不一样吧，内部创业不用焦虑团队下个月的工资在哪，但可能有身份焦虑，在大公司里如何找到自己的定位，也是有压力的。那出去创业必须要焦虑一件事情：团队下个月的工资在哪？你首先要解决这个问题，才能够谈其他理想情怀，所以你就必然要围绕着资本和营收去做，围绕营收去做，很容易偏离本心。这类走歪的创业故事非常多，我就不多说了。
+
+在大公司创业相对可以轻松自如去做，一定程度上压力是小于在外面创业的，但在产品上、业务思考上，很多方面压力也不会减少的，有时候也会变得更复杂一些，这是我的感受。
+
+小结时刻
+
+关于体验技术部的产品故事有很多，极客时间专栏《林外·专利写作第一课》，作者林外，是 Ant Design 的联合创始人之一，他曾经发文分享了 Ant Design 1.0 背后的故事，玉伯回复说：历史总是在经历时苦逼不堪，但在回忆时激荡不已。
+
+成功背后也许都要经历一些磨难，想要升级必须打怪。语雀在那些生死时刻一定也是苦逼不堪的，但冲出重围就是不一样的故事了。
+
+你用过语雀吗，在评论区说说你的使用感受吧，我们下一讲见。
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/08产品经理能力进阶：用户洞察、抽象设计到看到远方.md

@@ -0,0 +1,112 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            08 产品经理能力进阶：用户洞察、抽象设计到看到远方
+                            上一节和玉伯聊了语雀的发展史，部分内容涉及玉伯对产品的理解，这一节继续围绕产品话题，聊一聊究竟产品经理是一个什么样的岗位，产品经理的基础能力模型是什么。
+
+
+
+极客时间：依据你这么多年做产品的体会，你觉得应该如何定义产品经理这个岗位？
+
+玉伯：我可以聊聊产品经理应该具备什么能力，拿语雀举例，我觉得产品经理需要具备三个核心能力。
+
+第一个核心能力是，产品经理必须要有需求洞察力。需求洞察力从哪里来？一个最关键的来源，是来自产品经理在特定领域的专业知识积累。比如做语雀，得对文档，对知识库，对传统的知识管理，以及知识协同等领域有体系化的理解。比如对历史上的卢曼卡片法，比如新近流行的双向链接，甚至最早期的互联网里网页与网页之间的连接，以及知识网络等等概念，作为产品经理，都需要去探究究竟是怎么回事。产品经理要把产品所在领域当成一个专业去钻研，要长期有兴趣，领域知识的专业积累非常重要。
+
+领域知识的积累是一个产品经理具备需求洞察力的核心要素。此外，需求洞察力来自产品经理对用户的好奇，知道用户在什么场景下会去用这个产品，用户的使用路径是怎样的，使用过程中的心理状态是愉悦的还是有挫败感，用户会用产品里的什么样的功能去具体完成什么样一件事，等等。作为产品经理，要对用户的用法能感同身受，要有一种灵魂出窍和灵魂附体的感受。
+
+产品经理的第二个核心能力是，必须要有抽象和设计能力。产品经理在日常工作中，经常干的活就是逻辑抽象和设计，你在做产品的时候可以洞察到很多用户需求，但你不可能每个需求都用一个产品功能去实现，删繁就简的过程，就需要抽象设计能力。
+
+拿语雀举例，我们在文档里设计了斜杠命令，这是一个功能抽象。用户在写文档过程中，很多情况下写着写着可能需要快速插入一个卡片或者是一个链接之类的。在这个使用场景下，人眼的焦点在光标处，如果不用点击菜单而是直接在光标处快速唤起功能的话，效率会更高。如果不抽象成斜杠命令和斜杠面板，我们得把所有功能罗列在工具栏上。抽象设计往往没有对错，内蕴的是产品设计理念，产品经理的不同喜好，会带来不同的设计方式。比如我们一直没有做即时浮动工具栏，因为我们觉得浮动工具栏虽然便捷，但同时对专业用户是个强打扰。任何设计，往往都有利有弊，很难去谈对错，更需要的是取舍平衡。在抽象完之后，作为产品经理，还要能够与团队一起，去用 PRD、设计稿把具体设计做出来，抽象和设计能力是一体的。抽象是把需求化繁为简，而设计是化抽象为具象，这是产品经理的第二个核心能力。
+
+产品经理的第三个核心能力是，需要有未来洞见和规划决策能力。这是我自己这么多年的体感，也是现在对团队里高级产品经理的一个要求。能够看见用户需求，把用户需求经过抽象、设计转化成一个产品功能，这是产品经理的基本能力。要把一个产品做长久，还非常需要产品经理的长期的洞见和规划决策能力，面对纷纷扰扰的各种用户声音时，面对各种相关方的质疑甚至否定时，产品经理必须要能看见未来，能和核心团队成员一起有内心的笃定，同时面对各种短中期的利益时，能有取舍判断力，敢于说不，同时又能不伤着对方，能保持长期友好的合作态度。面向未来的规划和决策能力，特别难，但这往往是优秀产品经理进阶的必由之路。
+
+极客时间：我看到语雀里面有很多用户，无论是在知识库里还是其他地方，都会给你们提很多建议或者需求，小到某个功能怎么改，大到语雀未来应该走什么方向，你是怎么看待这些需求的？你有没有印象非常深刻的用户的需求。
+
+玉伯：用户的声音确实蛮多的，现在每天都能收到几百个反馈。面对这么多反馈，首先我觉得要分清楚两个概念：用户反馈和产品需求是两个东西，绝对不能直接把用户反馈当成产品需求。从用户反馈到产品需求还需要经过产品经理的专业转化，有些反馈可以经过抽象与设计之后，变成一个有效产品需求。
+
+更多用户反馈，反映的是用户使用过程中的情绪，反馈是用户情绪的一个出口。作为产品经理，非常有必要去看用户反馈，这也是我们团队的基本要求。同时，作为产品，在看反馈时，需要在看见一个个具体的反馈后，能在晚上闭上眼睛睡觉时，对用户群体有个感知，知道有哪几个用户群体，每个用户群体当前使用产品时，普遍的情绪是怎么样的，每个用户群体，看重的产品功能究竟是什么，普遍期待的产品改进又是什么。能闭上眼睛时，脑海里有一幕幕电影般的用户印象。
+
+做产品还要有个心态，叫“弱水三千，只取一瓢饮”。张小龙说，每天都有一亿人教他做产品，语雀也是，每天也有几百人在教语雀做产品。这么多用户反馈里，能抽象总结出来的产品功能点，往往也是非常非常多。是否都要去做？还要取决于产品团队对产品本身的思考和定位，同时还要考虑到团队的产研能力，是否有精力去实现某个功能后，能长期有效发展下去。这里有很多很多交集，每个交集下来，都是弱水三千取一瓢，最后从一瓢瓢里，不断取下去，剩下的最后一瓢，才是当下需要去做的。
+
+极客时间：用户反馈不等于产品需求，可以讲个案例么？
+
+玉伯：什么叫用户反馈，什么叫产品需求呢？这个蛮有意思。拿最近的一个例子来说，有一个语雀用户，很生气地给我们反馈一个事情，他说为什么我们写的文档发出来后，无法看到有谁读了？
+
+他希望某篇文档可以在有人看了后，他可以看到具体是谁读了，有没有读完，如果在规定时间内没看，语雀需要进一步提醒，不断倒计时提醒用户去阅读完成。对产品经理来说，这是一个文档的指定人群已读并提醒的功能，从技术角度讲，是可以去实现的。但如果真去做的话，就会发现这种需求做不完的。从语雀当前的产品定位来看，这个例子中的需求，就只是一个用户反馈。
+
+后来我跟他深入沟通这个事情，问他为啥需要这个功能，了解到原来他在负责公司培训的事情，有一些培训材料要提前发给学员看，他想保证学员在上课前都已看过。我后来就问他公司里在用什么办公软件，用飞书还是钉钉，他说用钉钉。我说你可以拉一个群，把语雀文档发到群里，用钉钉已读未读来看大家是否已收到。钉钉已读虽然不等价于文档已读，但已经能解决很多。后来这个用户还自己研究出来了更好的解决方案，用钉钉的消息标签功能来做，让已读的同学在读完后，主动加一个已读的标签。
+
+有时候跟用户沟通，深入了解使用场景后，往往用户自己就能找到合适的解决方案。但确实，有些情况下，与用户越沟通，会彼此越焦躁，用户的情绪甚至会被激发出来，会非常不理解语雀为什么不去做他想要的某个功能。这时，只能说抱歉了，冷静客观地说清楚我们的想法就好。客户第一这句话，讲的并不是把所有客户都当成第一，而是要分清楚，这么多客户里，哪些是语雀的第一客户，哪些是第二客户。分清楚后，做到有理有据有节，就好。
+
+极客时间：拒绝用户反馈时，是不是也要看场景的大小呢？
+
+玉伯：这取决于产品定位。需求永远是无穷无止境的，如果什么需求都去做，这个产品就会什么都是，从而什么都不是。产品要有定位，有了定位就有了边界，有了边界才能清楚哪些需求应该做，哪些需求不应该做。
+
+产品边界具体是什么？往往是探讨产品定位时，团队共同确定的一些共识约定，也包括共识的一些产品价值观。产品的价值观，往往就是团队的价值观。所谓价值观，最简单理解，就是你对一件事对错的判断，一件事情你觉得正确，是因为符合你的价值观，反之，一件事情符合你的价值观，你往往就会觉得是对的。像刚才那个用户的需求，希望能看到具体有谁读了文档，在我们的认知里，是有违背我们的价值观的，因为这涉及到用户隐私。真要做，也要分场景。在办公等互信场景里，因为已经在一个彼此了解的环境下，一篇文档具体谁读了的信息，是可以考虑公开的。然而进一步思考，语雀倡导的是轻松愉悦的学习工作氛围，如果自己是否阅读了某篇文档，是文档作者可看见的，那么就会对更多用户造成必须要去读完的心理压力，甚至会逐步引起同事与同事之间，在这种小事上的竞争，容易带来一些不必要的内卷。最后综合各种考虑，虽然这个用户的需求有其合理的使用场景，但语雀并没有选择去实现。
+
+对于刚入门的产品经理，我们会让他去看用户反馈，一方面是让他增强用户体感，一方面是在训练他如何去真正看到用户需求。很多时候，用户给的反馈，你以为是一个需求，其实不是，而是用户在给你解决方案。比如“文档能指定别人阅读，能展现已读未读状态”，其实并不是用户需求，而是用户在给语雀提供解法，他真正的问题，在反馈里并没有告诉你，这在用户反馈中非常常见。分清楚什么是用户反馈，什么是产品功能，这是产品经理的第一课。
+
+推荐一本书，叫《学会提问》。很经典的一本书，教你学会提问。产品经理有时候要反向看清楚这些问题，因为有大量的人向他提问。一个经典方法，是产品经理要学会 XYZ 思维。用户给你的是 X，你要去挖背后的 Y，甚至这个 Y 还是解决方案，你要继续挖 Z，你要挖到三四层才会知道原来用户是遇到了怎么样一个具体问题。张小龙在《微信背后的产品观》里也讲过，比如很多人都希望朋友圈有分组，挖到最后的需求并不是要分组，而是大家发朋友圈不想让部分人看见。不想让部分人看见那就有不同的解法了，在微信场景里，分组就不是最优解法，微信最终选择的解法是定向屏蔽。
+
+极客时间：语雀的用户中，有没有超过你们预期的使用行为？比如你们本来没想到他会这么用。
+
+玉伯：这个还蛮多的，因为语雀只是工具，这个工具可以做什么，更多是交给用户去发挥。就如你买一把刀，用来切西瓜还是切菜，这是用户的选择。
+
+印象中很深刻的一个案例，是北大附中使用了语雀，除了常规的文档和知识库用法，我们发现，北大附中居然用语雀的话题功能，来组织同学进行线上辩论赛。参与的同学都很认真，一个话题，正方和反方发言有理有据，彼此讨论非常热烈。使用语雀来进行线上辩论赛，在北大附中老师主动跟我们说之前，我们自己都不知道语雀还能用来干这件事。
+
+极客时间：对于高级产品经理的要求是未来洞见和规划决策能力，可以再具体解释一下么？比如拿语雀来说，未来洞见应该体现在哪里？
+
+玉伯：面向未来的洞见力，是指能看到更大的一个局，能想到这个产品三五年之后是什么样子。比如我们去看个人版语雀时，它的文档和知识库是可以公开的，这个公开看起来就是一个知识库文档的公开能力，但这个公开能力真的往下探，它究竟在解决用户什么场景的问题？有可能的机会点在什么地方？我们需要去想这些问题。目前语雀个人业务做了一个升级叫做数字花园，最最简单的理解就是新一代的博客专栏，我们会通过数字花园这个概念去把这个理念做包装，那为什么不叫专栏博客呢，这里面就会涉及对未来的理解。
+
+洞见来自于什么地方？往往是来自历史，来自产品经理对过往的观察。比如说我们提到的数字花园，是我们发现，团队内部很多同学，包括我自己，不太逛朋友圈，也不大逛微博了，公众号也不太看了，抖音有时候会刷，但刷完之后很空虚。我们就在想这究竟是为什么。刚才谈到微博也好，朋友圈也好，所有这些产品都有一个共性：它们是基于时间的信息流或者内容流，都有一个 Timeline，让用户活在一个个时间流里。时间流产品一定是满足了当下很多用户的需求，但同时会让一波用户感到焦虑，想远离。
+
+所以我们在想除了时间流之外，是不是还存在空间流，空间流的基本结构是怎样的，空间流是否能解决用户的焦虑问题，是否有可能构建一套更好的信息消费形态。比如说我想去了解某个人，我去微博上或者朋友圈上看他发了什么，只能了解他最近的一些情况。但如果这个人能够把自己的一些体系化知识、学习资料等按知识库分门别类的方式构建出来，形成一个个知识空间的话，那这个东西是从时间流里面脱离出来的一种空间沉淀。这个空间的沉淀就像花园里的景色一样，我们称之为数字花园。这是语雀很宏大的一个设想。
+
+极客时间：我还有个特别好奇的，你说现在每天都会有几百条用户反馈，这个反馈量开始有多少，大概是怎么样的波动情况呢？
+
+玉伯：最开始一天只有几条，后来快速增长到了每天一两百条，现在每天有四五百条，还在持续增加。我们同时有在做一些观察和调整，希望反馈量的增速是收敛的。如果用户反馈量一直涨，往往意味着产品有问题。同时，如果没有用户反馈，那是更大的问题。
+
+面对用户反馈，不能焦虑，语雀目前积累了几十万条用户反馈。曾经我们这边有一个运营同学，想做数据挖掘，想通过科学的数据分析之后，从这一堆用户反馈里推导出语雀应该做什么产品功能。曾有一段时间，我们迷信过这类数据，但最终发现这个方式不对，走过一段弯路。
+
+极客时间：这个讲一讲为什么是走弯路？他是有分析出一个什么决策发现不行，还是说其实通过数据分析也分析不出来啥？
+
+玉伯：因为最后我们发现，数据的真正作用是辅助决策，数据一定不能绑架决策。
+
+举个例子。曾经有段时间，我们挺焦虑语雀的用户增长，开始学其他网站做拉新，比如未登录时不让看，通过这种方式拉升注册用户数。从数据上看，用户注册数的确增加了。但同时，时常也会有用户反馈不好用，发给对方的语雀链接，对方看不了。这类反馈虽然不多，但每次看到时，总觉得哪里不太对。
+
+后来我们把登录拦截去掉了。拦截虽然能带来短期注册上涨，然而用户的不爽，会影响产品的长期发展。做工具，还是得有良心，这是一个感性判断。
+
+还有其他一些案例。我最大的一个感触是，一旦看数据很容易短视，这让我后怕。最终我们的经验是，数据是辅助决策的，最终决策还是得来自于产品的清晰定位和团队的长期信心。这不是说不应该看数据，而是要不断提醒自己，应该去看什么维度的数据。语雀目前最核心的两个指标，一个是付费客户数，代表有多少客户认可语雀，能让语雀长期健康发展下去。
+
+语雀还有一个核心指标是自然留存率。自然留存率反映的是语雀的基础产品力。当用户来了语雀后，有多少用户会注册使用并长期留存，这是很关键的指标。如果一个用户主动想来用你，但你连这种用户都留不下的时候，这个产品就很危险了。当这个指标发生变化的时候，大概率表明什么地方出问题了。比如有段时间我们的短信服务验证码出了问题，导致自然留存率就暴跌，因为用户收不到验证码根本进不来。通过数据的反映，我们赶紧去解决这个问题。
+
+找到一个好的数据指标挺难的。去找到合适的指标，也是产品经理的一项关键能力。语雀确定这两个关键指标，花了大半年不断讨论才达成共识。
+
+极客时间：开始会看什么维度的数据？日活月活这种看么，如果数字很好的话，人性使然，人们还是更多愿意说这种证明产品很好的数字，或者叫虚荣指标。
+
+玉伯：早期我们会看 MAU（月活）、DAU（日活）等数据。语雀的 MAU 很早就过千万了，但后来我们才想清楚，如果付费客户数没上去，MAU 越高，成本越大。
+
+除了月活日活等流量指标，我们也会关注营收、用户平均使用时长等指标，会出现大量指标，充满诱惑。但一定要认识到，虚荣指标只是虚荣指标，并不代表产品的健康发展。
+
+从这么多数据指标里，去找到符合语雀的关键北极星指标，需要不断去思考。比如，究竟语雀的业务方向是什么，语雀团队的竞争力在哪，语雀究竟有哪些重要用户群体，对用户群体提供的核心价值究竟是什么，把这些问题都逐步想清楚后，才能最终把关键数据指标确定下来。
+
+小结时刻
+
+关于产品经理能力进阶，这一节你可以关注：
+
+
+产品经理的三个核心职责范围：需求洞察力、抽象设计能力、未来洞见和规划决策能力。
+产品经理的第一课就是分清什么是反馈，什么是需求。
+产品经理要具备需求洞察力的前提就是领域知识的积累。
+如果一个用户主动想来用你，但你连这种用户都留不下的时候，这个产品就很危险了。
+时间流产品一定是在当下满足了很多用户的需求，但同时会让一波用户感到焦虑，想远离。
+找到核心指标是产品需要关注的，语雀的核心指标是自然留存率和付费客户数。
+
+
+留个小问题，你所负责的产品的核心指标是什么呢，欢迎分享，我们下一节见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/09个人成长关键词一：全情投入.md

@@ -0,0 +1,97 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            09 个人成长关键词一：全情投入
+                            玉伯曾经做过一个分享，名字叫《我的前端成长之路》，这个分享是在回答一个问题，11年里，对自己的成长来说，最关键的是什么？他自己总结了三个关键词：全情投入、守正出奇、愿等花开，针对这三个关键词，我们和玉伯进行了更深入的沟通。如今，全情投入是目前对他来说更重要的关键词。
+
+
+
+极客时间：想请你聊聊技术人成长的话题，你之前在内部的分享中提到三个成长的关键词：全情投入，守正出奇，愿等花开。现在这三个词对你来说依然很重要吗？有没有什么变化？
+
+玉伯：这三个词是我几年前的总结，对我自己的影响也蛮大。现在来看，会觉得全情投入是最重要的。无论工作在什么阶段，都需要全情投入。
+
+很多时候，会想不清楚自己想要什么，或很容易想得太大。要谨慎去想人生价值、人生意义这种非常大的话题，想多了容易陷入虚无主义。我的经验是，关注具体的目标，关注短中期的目标，做到全情投入，忙起来，人会更容易快乐。
+
+极客时间：忙起来还分这个工作是不是自己喜欢的，如果能忙自己感兴趣的事情，会不会更好，这是必要的吗？
+
+玉伯：我觉得不是必要的。很多人想不清楚自己究竟喜欢什么。很早就想清楚自己喜欢什么，是可遇不可求的。更多时候，需要具体投入到某件事，做到一定阶段，才能确认自己喜不喜欢。
+
+打个比方，作为文字工作者，写文章是日常，刚开始写的时候往往很痛苦，会以为自己不喜欢。但是坚持写下去，写着写着，有更多读者看的时候，或者当自己达到某种心流状态（写东西时不是脑子指挥笔，而是能感受到笔指挥脑袋的状态）时，往往就会喜欢上写作。跑步也类似。
+
+很多人总说找自己喜欢的事情做，我觉得有两种逻辑，要看是爱一行干一行，还是干一行爱一行。爱一行干一行，干的就是自己爱的，这是运气爆棚。先干一行，干起来，在干的过程中去确定自己是不是喜欢，或者开始喜欢上或讨厌上，这有更大的可行性。
+
+极客时间：如果我们最开始选定做某一个事情，某个方向的工作，那就先抛却杂念，全心投入进去，慢慢再去寻找吧。
+
+玉伯：与其选来选去，不如全情投入一件事情。因为一旦开始选择，就会有苦恼。天天想着寻找喜欢的，就会有失落，怕自己找不到，最终结果可能 99.99% 的概率的确找不到。
+
+极客时间：那你觉得你有寻找的过程么，不管是做技术，还是做产品，你寻找到了感兴趣的方向了吗？
+
+玉伯：我最终找到的方向，不是做产品或做技术这种分类方式，而是换了一种视角去看问题，会去看所做事情的价值在哪，这个价值会让我觉得活着有意义，这是一种经历过后被赋予的意义。
+
+很多事情要经历过后，才能通过自己或他人去赋予意义。比如，早期我在折腾开源项目时，天天干到两三点，经常腰酸背疼，虽然写了很多很多开源代码，但当时工作和生活状态都不是太好。我昨天讲述这些事时，你可能觉得我当时是觉得很有价值很有意义的，其实并不是。意义是在过了好几年后，回头看时，才发现那段时光，虽苦但很有意义。
+
+往大了说，经历过万里长征的人一定在过程中天天骂娘，你只有熬到了延安，新中国成立，再回头看长征过程，才觉得自己太牛了。万里长征、红军四渡赤水，都是非常有意义的，但这些意义都是后面才赋予的。
+
+所以我最喜欢的还是全情投入，当下要做什么样的事情，就把自己的全部精力投进去，不去想做完之后能够得到什么，能有什么意义。全情投入其实特别难，要把所有的杂念都去掉。
+
+极客时间：那怎么才能跨越这个难点，跨越这个坎儿，然后全情投入进去呢？这是非常理想化的情况，而且我觉得现代人的困境特别是年轻人的困境是很明确的，如果不想自己能获得什么，不想怎么利益最大化而只沉心做一件事好难。
+
+玉伯：现代年轻人挺有意思，我刻意观察过。他们特别容易全情投入，同时也特别不容易全情投入。
+
+比如出去团建，打王者荣耀，很多同学会很享受，打游戏时非常全情投入。同时仔细观察，会发现也有部分同学虽然在打游戏，但有些勉强，眼神是飘忽的。
+
+换一个场景，有些同学写代码时能心无旁骛，但如果去参加 PRD 评审，经常会默默坐在角落里，不太说话，不怎么融入。
+
+全情投入并不是一种态度，而是一种能力。比如能全情投入写代码的同学，为什么参加会议时无法做到全情投入？往往是因为这位同学比较内向，不敢沟通，心有害怕，在会议时想全情投入也很难做到。
+
+这需要提升自己的能力，比如当你面前不管站的是谁，你都不担心自己说错话，都敢于表达自己，能克服内心的恐惧，具备这种心态调节能力后，才能做到全情投入。
+
+提升能力，方能全情投入，打游戏也需要达到一定能力后，才能进入全情投入的心流。这是一个过程，关键点还是能力提升。
+
+极客时间：上面是在说在工作中的全情投入，那么在个人的成长中呢，你怎么全情投入？你也提到有早课的习惯，早上会有个固定学习的时间，现在还有吗？
+
+玉伯：我现在还保持着日课习惯。除了日课，还给自己增加了早课和晨课。日课、早课、晨课，是我的一日三课，这是我自己一直在坚持的小习惯。
+
+日课是干嘛的呢？日课时间很短，只花 5-10 分钟抄一些东西。前不久我在抄《金刚经》，让自己每天开始有一种仪式感，向先哲致敬，我花了大概四个月把《金刚经》抄完了。日课我只定时不定量。只定时是指，我到了公司后，前 5-10 分钟就用来抄经，抄多少不做任何限制，时间到了我就结束。这样会无压力，使得能坚持很长时间，成为习惯。
+
+早课是训练自己写作的能力，让自己的写作能力得到不断地刻意训练。工作日，会想办法给自己留出一个小时去写点东西。我会逼着自己在一周里面的写作练习不少于两次，现在能做到一周写 3-4 篇文章。
+
+比如说我前天写的主题是如何沟通，会把《非暴力沟通》等经典书籍再翻一翻，同时结合实践，总结一些心得写下来。昨天写的是“什么是幸福”，是一种意识流的东西，会刻意去捕捉脑海里对幸福的思绪，比如“幸福就是好的变化”。
+
+晨课就是一日之计在于晨。晨课很简单，每天早上会花 15 分钟左右去规划今天具体干什么。比如去参加哪些会议，要完成哪几件事等具体日程安排。
+
+一日三课，这是我每天的微习惯。
+
+
+
+极客时间：你前面讲的这些，其实感觉是有点活在当下的理念。
+
+玉伯：全情投入就是活在当下。
+
+对活在当下的感触，很大程度来自对日课的坚持。每天5-10分钟的日课，让我这几年抄完了《论语》《道德经》《庄子》《孙子兵法》《金刚经》，最近在抄《楞严经》。
+
+抄的时候是不求甚解的，仅仅是抄，感受文字本身。很多文字到现在我也不知道在讲什么，但是当我反复抄时，过程中开始不断有新感悟。比如佛学里谈及的我相、人相、众生相，我之前不太理解，在抄《金刚经》时，反复出现这几个词，现在再看到这几词时，就特别熟悉，像是老朋友，觉得一切是明明白白的。
+
+日课我只定时不定量，时间到了我就结束，只要是这个时间段，我只干这个事情。这种体验，完全没有压力，同时会有惊喜，比如会发现原来每天抄 5-10 分钟，3 个多月居然可以把《金刚经》抄完。这类经历，也会让自己真正理解“滴水石穿”、“功不唐捐”、“日拱一卒”是什么意思。以前只是认识了这些成语，现在通过经历真正感受过后，会有种敬畏感。
+
+极客时间：为什么会想做三课这个事情？
+
+玉伯：这是受一本书的影响，叫做《微习惯》，每天一个微小行为，能生成巨大的力量。这本书讲的是，很多时候人的行为，包括思维，都是由一些微小习惯组成的。
+
+日课是受《刻意练习》和《微习惯》这两本书影响，我是拿自己做实验，看到底坚持下来会怎么样。最早写日课是 2019 年，选择了定时抄书来实践，现在很感激自己的这个实验，让自己养成了日课的习惯，收获非常多。
+
+小结时刻
+
+人唯一的财富就是自己的时间，要对自己的时间负责。最好的时间管理，就是全情投入。
+
+最后，留个小问题，你在日常生活中有什么持续坚持的小习惯么？欢迎在评论区分享，我们下一讲见！
+
+延伸阅读
+
+我的前端成长之路
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/10个人成长关键词二：守正出奇.md

@@ -0,0 +1,109 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            10 个人成长关键词二：守正出奇
+                            玉伯总结第二个成长关键词是守正出奇，那么对于一个技术 Leader 和业务 Leader 来说，什么是正？什么是奇？他又是经历过什么故事，才得到这样的体悟呢？这一节，我们就围绕这个词展开吧。
+
+
+
+极客时间：守正出奇（qi）也可以读作守正出奇（ji），“出奇”可以解释为出奇制胜，也可以像你一样解释为要有多余的部署。从技术团队角度讲，你认为什么是正，什么是奇呢？
+
+玉伯：回到《孙子兵法》去看，“以正和，以奇胜”，是指两军对垒时，你的正面要守住，同时其实你还有一支很强悍的，也是人数比较多的军队去突袭对手，你就胜了。
+
+我当时提守正出奇这个点，核心是让大家理解对我们来说“正”是什么？技术团队的本职工作就是产品研发，这个正是不能丢的。你不能说公司给你安排的活你不干，你去干其他的，这就不叫守正出奇了。当技术团队本职工作没有守住的时候，你去做一些技术创新，可能很容易就做歪了。
+
+所以守正出奇的前提条件是团队 Leader 对这个“正”本身有足够的理解，真的是能够坚持把这个“正”给做好了，因为这是基本盘。奇（ji）就是多一点的意思。多一些人力和时间去做更多事情，才能赢取胜利。
+
+极客时间：你带领团队一起做了很多创新产品，对你们来说做的这些事算是“正”还是“奇”呢？在这个过程中有没有偏离“正”的时候？
+
+玉伯：这个问题我也很有体悟，曾经因为没深刻理解这个词，导致有些产品夭折了。
+
+做创新产品的第一步，是选择产品方向。华人管理大师杨国安教授，有一个著名的杨三角理论，是说在做一件事之前，请回答“团队愿不愿意做？”“有没有能力做？”“市场、公司容不容许做？”这三个问题。
+
+
+
+我曾经在内部做过一个产品叫做“九色鹿”，大家应该没有听过，是一个洞察分析平台，或者叫流量分析平台，可以分析一个网站或应用的流量点击情况、整体的用户河流图等等。因为我们当时在做数据可视化，又有人懂全栈开发，我们拿杨三角理论一分析，觉得我们应该是具备可能性的，就去做了。
+
+怎么分析的呢？一是觉得方向不错，我们愿意做。为什么是我们做？因为我们有能力做。公司允不允许做呢？公司也没说不允许做，那我们就感觉这件事靠谱，大家就干吧。
+
+但这个产品发展到第三年第四年的时候，就发现我们当时的判断是错的。
+
+首先公司不允许我们做，更适合做这件事的团队应该是数据平台，数据平台去做流量分析平台更合适。我们即便要做，也得是帮助数据平台去做这个产品。所以这个产品最终是交给了数据平台团队。包括我们当时回答“有没有能力做”这个点，也有点乐观，后来发现其实我们也缺失数据分析 BI 这块能力的。对于前端来说，要去学包括 ETL 等技能，可数据挖掘这个领域挺深的，我们低估了难度。
+
+最终发现这件事只剩下我们愿意做，有意愿，但实际能力有欠缺，公司也不允许。最后这个产品交接给了数据平台团队，我们继续做前端研发。
+
+极客时间：你们做前端支持工作，这样搭配起来是更合适的对吗？对你们来说，这次“出奇”其实没出对？
+
+玉伯：对，这是一次失败的创新尝试。我们原以为是奇，但其实不是。我们更应该的是帮助对方去把这个产品做成，这才是正，是我们的本职工作。但是我们把它当成了奇去做，这就变成了抢地盘。守正出奇，奇没定义清楚的话，往往就会变成抢地盘。
+
+极客时间：九色鹿这个团队毕竟做了三四年，当时团队有多少人？最后这件事对大家有什么影响吗？
+
+玉伯：九色鹿一开始是三个同学，到后来是我们成立了正式团队去做。九色鹿团队是我第一次解散一个团队，是让他们去做其他事情，并不是离开公司。
+
+说到这里，其实除了九色鹿，我们团队还做过一个存零花钱的项目。后来也发现并不合适在我们团队继续去做，最后交出去了。交出去，是为了这个产品更好发展。一个产品在不同阶段，往往需要不同的能力。
+
+极客时间：经过这两件事，两个送出去的产品，会对你们团队产生不好的影响吗？在项目里的人肯定比较伤心吧。
+
+玉伯：当然会，短时间来看影响一定是负面的，大家士气都很低，特别是身处其中的同学很受打击。甚至后来有几个同学都去了其他团队，因为确实情感上接受不了，相当于自己生了个孩子，最后要送给别人。短期对团队是有打击的。
+
+但从长期看，大家能经历这么一场是好事，因为经过这些项目，才能真正看清楚，守正出奇的“奇”是什么，创新的方向应该如何选择。不是你做一个创新就是奇，而是你要找到适合本部门的创新才叫守正出奇。
+
+去做一件新事情时，一定要思考清楚“为什么是你做”这个问题，一定要把这个问题先回答清楚。这个问题想得越早越清楚，越能减少遗憾，越能让想做的事情真有机会去做成。
+
+极客时间：做了决定要把项目叫停的时候，你肯定也要跟同学们说为什么是这个结果，叫停的过程你也说大家很痛苦嘛，那对你来说你面临的痛苦是什么？
+
+玉伯：痛苦是回想起来很痛苦，当时更多是觉得很难。
+
+难点之一，就是如何解决情绪问题。大家对自己做的东西有情感，人有情绪的时候你是很难去沟通的。
+
+难点之二，是如何说清楚为什么要叫停。要说清楚停止的原因，要么拿数据，要么拿逻辑，只有这两样东西。在内部创新产品中，数据往往不能用，大家会说坚持长期主义可能数据就涨起来了，是要被挑战的。这跟外面创业不一样，在外面创业可以说没钱了，所以解散。最终我只能用逻辑来说明原因，可因果这东西，其实往往只是相关性。
+
+最终，还是从理性上讲逻辑，让大家理解，从感性上晓之以情，让大家接受。
+
+真正接受，还是得靠时间，可能要几个月。比如说九色鹿，有个同学两年以后才真正释然。
+
+两年以后才释然，是因为他后来也做了一个类似的产品，知道原来内部创业是这么不容易。他真正理解那个 WHY 了，领会到了不是当时玉伯不让做，而是真的很难做。其实人的成长是自己的事情，主管也好，同学也好，只能帮他。他能不能成长、转变，取决于他自己。
+
+现在我们立项时，会把一些问题想得更透彻后再去做，做的过程中如果发现走错了，不管是因为早期的贪婪也好，过程中做错了也好，都要果断停下来。停的过程是挺痛苦的，因为你会跟长期主义理念做博弈，会想也许再坚持一会儿可能一切都顺理成章了。但最终得到这样的结果，还得认知到一点，就是运气也是成功的必要因素，不必放大长期努力的因素。
+
+一定要敬畏运气，运气往往代表着你所不知的各类环境要素。运气是天时地利人和，运气和很多因素相关。我们很容易崇拜名人名言，但其实每个人都可以说名言啊。你相信某个人说的某句话，背后是因为这个人做成了一些事情，人的大脑会潜意识地做归因，会觉得是因为这个人有这些认知才做成了这件事，但实际上很可能运气占很大成分。我们要谨慎看待“名言”。
+
+极客时间：对于团队 Leader 来说，当你看到一个新项目的方向，去判断到底是正还是奇，这是非常关键的问题。经过九色鹿和零花钱这两件事，肯定也让你积累了很宝贵的经验。
+
+玉伯：对，所以回头看，无论是发起一个技术产品还是创新产品，我们要回答好灵魂三问：Why？Why us？Why now？就是这三个问题。Why 是从整个大市场环境来看，你为什么要做？比如说你现在说我要做个微信，但是这个 Why 就说不过去了，已经有微信了，你凭什么要做？你要做，你也得切其他的一些细分领域，或者是说跟微信不一样，你才有机会，这是从整个大环境去看你做这个产品的可能性和机会点。
+
+第二个问题，Why us，为什么是我们来做？像九色鹿也好，零花钱也好，很多时候是 Why us 没有回答好，我们傻傻地以为我们愿意做就等于我们就可以做。如果是技术产品的话，要看公司团队里面各个职责分工，比如我们作为大前端团队，对于前端的一些基建，我们来做是非常理所当然的。但这个时候比如你要给 Java 开发工程师去做一个 Serveless 平台（其实我们也尝试过，但是很快又转方向了），就发现其实我们这个团队不是最适合的，交给 Java 团队、中间件团队会更合适。
+
+第三个问题 Why now？为什么是现在做？因为你做早了肯定是炮灰，你做晚了也没机会了。那你要去判断当下哪个这个时间点可能是最合适去切入的。
+
+极客时间：聊到这，相信大家对守正出奇这个词有更深刻的理解了。对于你个人经历，我还有一点好奇，外界对你的印象很多还停留在前端大牛的标签上，但是通过你分享的这些经历，看出来你一直有颗产品心，一直都在做产品，所以从技术岗位到产品其实是很平滑的？这算不算“守正出奇”呢？
+
+玉伯：传统意义上，大家可能觉得像语雀才算产品，但我自己一直不太认可这个逻辑。我之前在淘宝的时候做开源，那些开源技术我也当成产品去做的，技术本身也是产品。或者说我一直以做产品的心态去做技术，那么我一开始就是在前端领域里做产品。
+
+对我来说，可以叫从技术产品转向业务产品，这是变化比较大的。第一个让我感受到不同的就是零花钱项目，当时我招了一个不错的运营同学，很优秀。做这个产品过程中，对我最大启发的就是这位运营同学，他会不断强调说“产品就是运营，运营就是产品，产品和运营是一体化的”。现在我很容易理解这句话，但是当年我非常难以理解，为什么说运营就是产品，产品就是运营，这不是忽悠我吗？
+
+现在我理解了，我们谈运营总离不开拉新促活、AARRR 用户分析经典模型等等，但是本质上如何拉新要回到你的产品，特别是产品 0-1 的阶段，如果你的产品力本身不行，运营来了十个就会走十个，是留不下来的。“产品就是运营，运营就是产品”强调的是产品留存率，运营要有效果的话，那么产品留存率一定要达到一个值，比如来十个人能留住六个，这个时候来一百个就能留住六十个。这还是最粗浅的理解。运营和产品，就和人的左脚和右脚一样，都具备，人的活动才自如。
+
+极客时间：是不是产品在 0-1 的阶段，必须要有自然增长才能往前做。不同类型产品的留存率定义也不一样，很难找到一个标准，比如 10 个能留下 4 个也是能投入的，所以判断能不能投入，其实还是要看个人的洞见。
+
+玉伯：要看具体情况。十个留一个是对的，十个留十个也是对的，取决于一开始选择的用户池正确与否，如果选错了，那十个留零个也正常，因为目标人群搞错了。比如小天才手表给大学生推广，那肯定一个也留不下来。这个过程中的启发就是，除了留存率或者自然增长，运营还要回到用户人群定义上，其实本质上跟产品的思考是一样的，运营要想的点跟产品想的点在基本盘上一定要有强烈共识，最好是一套，否则就会有拉扯，产品说我们是给中学生服务，运营说我推广给大学生，就无法匹配。
+
+运营和产品的关系，也分阶段。一开始往往是“运营是运营，产品是产品”，彼此不太理解，有内耗有拉扯，磕磕碰碰，往后发展是“运营就是产品，产品就是运营”，开始一体化思考，对很多地方都开始有共识，然后再往后，还是会回到“运营还是运营，产品还是产品”，就和左脚和右脚一样，虽然都是脚，但还是分开的，同时能良好协同，能健步如飞。
+
+极客时间：对于产品和运营在什么阶段应该怎么配合，你有这些体悟，除此之外从技术产品到业务产品，还有哪些让你感受不同的地方？
+
+玉伯：从技术产品到做业务产品最大的变化，就是对技术、产品、运营整个理解会更有层次。不像之前做 Ant Design 的时候，那时候我们也做运营，但是那个技术就是运营，运营也是技术，在技术圈子里面靠个人影响力，不断增加 Star 数，项目做得好的话，也会上 GitHub 趋势榜，等于平台帮助你做了运营，莫名其妙你就有这么多粉丝，技术产品更多在做技术合作，通过社区做影响力顺带做运营。
+
+之前我们在做前端开发支撑业务的时候，虽然天天服务运营，但很多时候对他们做的事其实也不太理解，总是搞红包拉新，那会觉得天天搞什么不靠谱的东西，但现在我肯定不这样想了。这是业务产品带给我的改变。
+
+小结时刻
+
+守正出奇的前提条件是团队 Leader 对这个“正”本身有足够的理解，守住本职工作，再去做创新。做创新产品第一步，要选择产品方向，无论是大公司内部产品还是外部创业，做决策前先回答“团队愿不愿意做？”“有没有能力做？”“市场、公司容不容许做？”这三个问题，谨慎作答后，才会更接近成功。
+
+你对守正出奇有自己的理解吗？听完玉伯的解释，你有什么感受，欢迎在评论区发表看法，我们下一讲见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/11个人成长关键词三：愿等花开.md

@@ -0,0 +1,93 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            11 个人成长关键词三：愿等花开
+                            玉伯总结第三个成长的关键词是愿等花开。愿等花开，就是长期主义。作为团队Leader如何带领大家坚持长期主义，从个人角度出发，玉伯自己又是怎么坚持长期主义的呢？这一节我们聊聊这些话题。
+
+
+
+极客时间：你曾经说如果真的笃定一件事，一定要学会等待，不要着急去催熟，包括你跟团队经常强调，做事要快但不能急，这就是你坚持的信条，文艺一点叫愿等花开。你是通过哪些事情，总结出来要坚持长期主义的？是一开始就这样想呢，还是事后总结？
+
+玉伯：在阿里做规划时，有个提法是看五年、想三年、定一年。我们团队在实践中也会有这个要求，比如说 2022 年年度规划时，会去想 2024 年整个团队会达到什么样的状态，应该做哪些重要的事情。
+
+坚持长期主义是我们团队的特色之一，已经变成了一种习惯。在阿里，很多团队都会用“五三一”去做规划，但是很多团队还是会偏短期，是因为经常容易会把规划跟 KPI、OKR 等考核周期绑在一起。我的做法是，会刻意错开，不跟公司财年或自然年绑在一起。比如说最近的三年规划，是 2021 年 8 月份去做的。为什么这么做呢？因为一旦跟绩效周期绑在一起，绩效没有完成的时候就会焦虑。哪怕是长期规划，执行时大概率也会变成短期绩效。
+
+公司对团队的定位，和团队想做什么，要双向去看。比如公司对于前端团队的定位和期待，就是要降本增效，要帮助产品体验提升，但是回到我自身去看这个团队，就不光要达成公司降本增效的目标，还要达成公司没有明示但会买单的目标，比如团队的长期可持续发展。不能说今天我们帮公司降本增效了，明天团队散了，公司肯定也不希望看到这个结果。公司对团队的目标是有隐性的，是要自己挖掘的，比如团队的可持续发展，比如技术的创新性和先进性，这些隐形目标，需要靠我们的专业度去看见，这很重要。
+
+举个例子，Ant Design 已经做到了西湖区第一和中国第一，最近我们对 Ant Design 的目标规划，其中影响力这块的目标就比较简单了，就是从中国第一变成全球第一。从 Star 数看，Ant Design 目前已经是全球第二，我们只剩下一个对手。我们以这种方式去定义 Ant Design 全球第一的三年目标规划，对公司来说，公司是不关心的，但是公司关心前端技术团队的人才吸引力、长期的稳定性。做 Ant Design 可以提升前端团队的人才密度，可以给公司带来良性的影响，公司是不会反对的。
+
+极客时间：具体来说看五年，想三年，定一年，在制定目标的时候大概会看哪些方面？
+
+玉伯：想五年更多是根据团队定位，比如大家知道目前大环境不太好，很多公司都在做组织优化。这时候降本增效一定是接下来三到五年被关注的点。那么在前端侧，如何做到降本增效？这就是我必须要考虑的问题。
+
+如何降本增效，关键策略是什么？比如什么样的业务应该用我们自己的前端支持，什么样的业务可以找外面的 ISV（Independent Software Vendors，独立软件开发商 ）独立交付，这些用工策略，都需要去思考。同时是否加大低代码平台的研发力度，是否可以降低技术门槛，是否可以实现人员的统招统培等等。在降本增效的方向上，就可以得到一些非常具体的规划。
+
+“看五年、想三年”的出发点，是站在公司角度去想，站在公司角度去思考如何降本增效，如何创新等等。结合过去和当下的一些难点，同时去看未来可能的发展趋势，再结合团队的实际情况，最后去制定今年和接下来三年做的事情。
+
+在这种降本增效大环境下，必须还要考虑哪些方向需要做取舍，让事情更聚焦。这也是守正出奇，现在必须得把正守好，如果现在出奇的地方太多，就容易失衡。
+
+再拿 Ant Design 举个例子，全球第一是我们的三年目标，但是同时这也是做了很大取舍的一个目标。比如 Ant Design 一直跟设计师团队走得很近，很早以来，就在探索设计工程化方向，这里面，有个梦想，就是想做“中国的 Figma” —— 一个在线设计工具，能够替代 Sketch。如果按照往年的情况，我们真的可能会投入人力做，但今年整体形势不好，“中国的 Figma”这个点子，在 Ant Design 大方向里面就被我们暂时砍掉了。另外，像 AntV 在智能可视化方面我们是非常看好的，还是会重点投入去做。所有规划，都需要取舍平衡。
+
+极客时间：这是以团队角度去看长期主义，因为你是团队管理者的角色。那比如说从个人成长角度，让我印象深刻的就是你坚持了几年的三课：日课、早课、晨课，以你自己的经历，要怎么坚持这种长期主义？
+
+玉伯：刚才是从团队规划的角度去看长期主义。但是坚持长期主义，同时要把守正出奇放在前面，一定要弄清楚哪些是正，哪些是奇，对于“正”的部分也要清晰中短期的里程碑目标，这样才能保证活着。然后“奇”的部分，比如 Ant Design 跟我们的“正”并不相关，至少当时做的时候不直接相关，这时候就要花三年去看结果。这是从团队规划、守正出奇的角度看长期主义。
+
+回到个人角度，坚持长期主义也是很好玩的事情，其实我一直没有太多的年龄焦虑，包括和一些同学聊天的时候，有时候都很难共情。很多人会关心自己 35 岁了，还没有到 P8，自己同时期的同学已经 P8、P9 了，会去比较。我不会这么去想，可能是和我在中科院物理所那时候的经历有关。那时候大家都要写论文嘛，很多很牛的一些 paper 是怎么写出来的呢？我就发现比如自己的导师或者学长，他可能前面几年就是写不出来，一直憋到研三快毕业了，他突然搞了一篇很牛的 paper 发表在《Nature》或者《Science》上，立刻就能毕业了。可能那些研二就写 paper 写得很顺的，即使写了很多篇，都不及最后人家发的这一篇。
+
+有时候很多人把自己和同事、同辈朋友去比较，觉得别人混得好。可能他就是比你早几年接触一些东西，但你反过来想，那我就大不了比他多活几年嘛。这么着急干嘛呢？我只要比他多活几年，什么都有了。你可以认为这是阿 Q 精神，但无论它是什么精神，重要的是去找到一种自我和解的方式，敢于用自嘲、自讽或者自我调侃的东西来打破焦虑。
+
+我曾经有过身高焦虑，但是后来应该在我高中长不了个子的时候就想通了，第一个，反正长不高了，改变不了啥。第二个，因为我们当时很喜欢姚明，姚明也才 2 米多，他再高也没有比我高出一米，就会觉得自己的身高也还可以，还会挺庆幸自己不是侏儒，身高焦虑就不见了。
+
+包括别人说我长得黑，后来我的办法是以黑治黑。经常在团队拍合照时，我们的口号是“玉伯黑不黑”，大家再一起说“黑黑黑”，很开心很治愈。
+
+极客时间：这种心态很好，能做到自嘲，自讽，很多时候也是自信的表现，特别有底气的时候才容易自嘲。你的自信是怎么建立起来的呢？
+
+玉伯：这个自信怎么来的我也不知道，我现在都觉得是个谜。比如姚明真的站在我面前，我也觉得你就是高出几十厘米，我没啥可自卑的。
+
+如果真要归因，我回想起来可能有两个方面。第一个方面和自己小时候的成长环境相关。我小学是在小山村里面，村里小学总共两个教室，叫复式班，很多人应该都没经历过。全校就两个老师，校长和副校长，他们要管所有课程。当时一年级跟三年级在同一个教室，然后分成两边坐，一年级上课的时候我们在做作业，我们上课的时候一年级做作业。这是老师的安排，但是我们都不听，一年级上课的时候我们全部出去玩儿，老师使劲喊，上完课了，你们赶快回来，然后大家才跑回去上课。
+
+小学阶段其实从来没有过学习方面的压力，真的是叫做山里的野孩子，当时小学是在山顶上，我们漫山遍野地跑，爬树都是很厉害的。这算是小学无忧无虑的阶段。
+
+后来上了初中，初中是非常乱的。我还记得这个寝室跟那个寝室拿着铁锹、铁铲互相干仗，当时我就经历过同寝室的人挂了，就是睡在我上铺的兄弟。中学时候看了很多武侠小说，甚至有时候感觉武侠就在身边。
+
+极客时间：这件事儿对你影响大么，那时候会感觉很害怕么？
+
+玉伯：当时觉得好像也没有那么恐惧，反正我现在回想起来就觉得这个兄弟走了，大家还是继续上课。当时还有打架斗殴被逮进去蹲监狱的，初中是非常乱的，到了高中这种情况才稍微好点。
+
+中学这个阶段可能因为自己的成绩还可以，就一直没有啥压力。我的成绩属于一直在全校前十名徘徊，我也挺满意，觉得能在前十就挺好，可以继续上学。当时有观察第一二名，学得也太辛苦了，我没有那种去卷的意识，一直到高三我才觉得可以好好努一把劲。高三的时候开始有月考，我一般是第三名，有一回从第三名跌到第七名了，我觉得这不行，就更努力了些，最后高考拿了第一名。我就发现自己只要稍微一努力，还是比较容易达成自己想要的。
+
+极客时间：是不是因为你学习好，比较聪明的原因，你就知道努力一定有结果的，所以能建立这种自信。
+
+玉伯：可能我比较幸运吧，学习成绩确实也算自信的来源。而且当时那些老师对我还都挺照顾的。上数学课的时候，我都是一个人坐在最后面，不用听这堂课，我自己学自己的。数学老师也挺好的，我觉得老师对我的影响也挺大的，因为我的数学已经很好了，他就说那你就坐后面去，你的时间你自己去安排，有问题的时候可以去问他。他说，“我的职责一定是去帮助很多成绩不太及格的同学”。
+
+老师会直接跟我说他的想法，到现在为止我都记得这句话，这对我的影响很大。你可以理解为当时这个老师就是我的 Leader，Leader 很多时候不是抓掐尖的，他的关注点是这个班级里他能够帮助到的更多的群体。这个对我其实影响挺大的，包括我现在的管理方式，有可能是当时受老师的影响。
+
+所以我觉得一方面自信来源就是从小成长的经历，一直到高考前，其实都没有太经受过挫折，还是比较无忧无虑地成长，成长环境里面有一种优势心理。多说一句，现在总有人说“女孩要富养，男孩要穷养”这种理论，其实无论男孩女孩都应该富养，只有富养，一个人的性格自信才会养成。
+
+后来从大学开始一直到工作，这种自信的形成，我觉得更多是发现可以依据自己的选择，决定自己的路。这是自己工作之后，自信心增强的很重要的原因。
+
+有两个事情印象很深刻，我高中在县里面考第一第二都是习惯了，觉得自己很牛，考到了中科大，当时我去物理系，我们是一个系就一个班，大概 100 人左右。大一入学后，有摸底考试，考完之后我看成绩，全班 100 多人里，我是第 102 名。当时我就觉得怎么会这样？那也是第一次到大城市，其实还是挺受打击的。后来我花了将近一学期时间，很快成绩又回到了中上游水平，然后就去玩各种兴趣社团了。我发现只要自己真正做某件事情，全心投入去做，还是能赶上去的，这是大一的经历。
+
+后来到了研究生，最终选择了退学。之所以敢下这个决心，也是跟大一经历有关，一直有一个很强的感知：自己做的选择不会错。有一种迷之自信，大不了再拼一把，有这种劲头在里面，包括工作后好多事情，比如开源做一些东西，都是这种劲头。这种劲头回到湖南人的性格里面叫吃得苦、霸得蛮、耐得烦。最终可能就因为自己是个湖南人吧。
+
+回过头来看，自信往往源自过往的经历。每个人的经历都不一样，从而养成的内在心态也就不一样。
+
+极客时间：我觉得你性格里面应该有很坚韧的部分，不容易被很多事情打击到，思考也很自由独立，好像也不太会被周边影响。
+
+玉伯：可以这么说，但这有利有弊。说得好听一点是独立思考，说得难听一点是傲慢偏见。
+
+回到坚持长期主义，这可能是我做事的风格，觉得一件事情既然认定了，就花一年去做，一年没有做成，不会太焦虑，会再看第二年，第二年不行再看第三年。如果花了几年时间证明确实做错了，到时再果敢放弃就好。
+
+和全情投入一样，长期主义本质上是种能力，能看见未来的趋势潮流，能找到方向，同时能内心笃定，能和团队一起坚持往前，加上非常重要的运气成分，才能真正等到花开。
+
+小结时刻
+
+长期主义需要定力与耐心，支付宝体验技术部孵化出的很多创新产品都是坚持长期主义的果实。在玉伯的语境里，全情投入、守正出奇、愿等花开，这三个词不是割裂的，而是相互交融的。坚持长期主义也要“以正合，以奇胜”，这样做产品才能走得更长远。
+
+性格坚韧者更能“愿等花开”，听完玉伯的解释，你有什么感受，欢迎在评论区发表看法，我们下一讲见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/12作为创新产品聚集地，体验技术部成长土壤从何来.md

@@ -0,0 +1,105 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            12 作为创新产品聚集地，体验技术部成长土壤从何来
+                            作为创新产品聚集地，体验技术部成长土壤从何来？为什么玉伯带领的这个团队能有这么多作品，他面临哪些压力，做了哪些努力，这个团队又是怎么运作的呢？接下来的两节内容，我们就来聊聊关于管理的，关于团队文化的话题。
+
+
+
+极客时间：支付宝体验技术部包括语雀在蚂蚁应该算是比较特色的存在，而且很多人觉得语雀和蚂蚁的主营业务没有什么直接的关系，但是你们还能做成这些创新产品，一方面高层允许去做这样的业务，是一种开放，鼓励创新。另一方面，你作为Leader肯定也为团队创造了很大的成长空间。在这个过程中有没有一些别人没有看到的难点和困难，你是怎么去克服的？你是怎么给大家创造一个土壤让这个团队去发展的呢？
+
+玉伯：回想起来，有碰到过不少难点和困难，过程中有些经验可以分享给大家。
+
+首先这个土壤不是有意为之，并不是我们要去创造土壤，然后通过一二三步，土壤就创造出来了。更多是在解决问题的过程中，自然而然出现的。体验技术部在 2013 年成立，2013 年我们就是扑到业务支撑上，在基础技术上的积累很少。到 2014 年才真正开始去做一些技术布局。布局的技术点，也是基于问题驱动的。
+
+举个例子，之前我们用 YUI3 开源框架，它是面向全球用户的，其中有一个组件，就是我前面说过的 AutoComplete —— 打开一个门户型网站，在搜索框去输入关键词，会出来搜索提示框，这个搜索提示框组件就是 AutoComplete 自动完成组件。
+
+这个组件很好，但对我们来说，性能有问题。当时国内网络环境一般，做性能优化需要从各方面去考虑。为了性能优化，我们仔细去看 AutoComplete 源码，发现它考虑了全球用户，在设计上支持很多语言。然而当时，淘宝只需要考虑中国用户，并不需要面向全球。这意味着对日韩语言的支持可以砍掉，还有对类似阿拉伯语自右向左的排版支持，也可以砍掉。这样从业务场景出发，就可以砍掉很多不必要的代码。
+
+不断思考后，我们发现还不如自己实现一个，实现之后体积只有原来的 1/10，对当时的淘宝来说，性能会好非常多。做这些事都是问题驱动的。这个例子讲的是在淘宝阶段，在支付宝做 Ant Design 的思路也是类似的，会发现自己去实现一套 UI 组件库，性能和各方面的指标都会比 YUI3 等开源组件库更好。这就使得我们开始有机会去成立一个虚拟专项小组，把 Ant Design 作为一个部门级项目，确定下来往下走。
+
+现在回过头来看，当时 2014 年这个决定就让 Ant Design 有了成长的土壤，这个土壤真正的来源是业务需求。基于问题提出解决方案，是成就土壤的第一步。
+
+后续的发展，更多和长期主义相关。我比较有耐心，基本上每个产品立项，更多是以开源和长期主义的心态去做，每一件事情，都会尽量能坚持至少三到五年。
+
+基于问题发现机会点，同时坚持长期主义，是为创新产品创造土壤的关键点。
+
+极客时间：在做这些事的过程中，公司层面会给你什么压力吗？
+
+玉伯：一定是有压力的。压力无所不在，比如业务会吐槽说，业务都这么缺前端了，玉伯你怎么还让团队去搞开源，会被不理解。永远会有这种声音，一直没停过，到现在都有。
+
+面对压力，重要的是要去分清楚什么是真压力，什么是假压力。如果真的某个业务线很紧急，在某个时间点就是要上线，这个时候一定要和业务绑在一起，从创新项目里把人员抽出来，优先保证紧急业务上线。
+
+另外，说到这我补充一句，我总提的长期主义，一定程度上也是被逼出来的。因为我们人员一直没有太固定，很多创新产品开始时就是个虚拟小组，并没有全职投入的同学。比如参与 Ant Design、AntV 这些项目组的成员，绝大部分情况下他们都是兼职，他们本身有项目压力。有项目压力的时候要先保证项目。优先级上，默认就是业务优先的。
+
+同时在团队文化里，很长一段时间，我们会一直强调“业务先赢”，最近几年的提法变成了“业务和技术要双赢”，一直以来就是业务优先的，这是大量团队的基础共识。在这种业务为先的背景下，技术的长期主义往往是被逼出来的，因为时间不可控，因为是兼职，会导致很多事情就是得以半年为维度去规划，才会有进展。你很难按正常全职方式去做 Ant Design，规定一个月要出来什么、两个月要出来什么，如果这样做的话我们可能什么也做不出来。
+
+真压力都好说，无非是优先级的调整。日常更多面临的压力，是假压力。
+
+假压力就是别人对你的评价，比如有人说前端不好好支持业务，天天去瞎搞开源，然而仔细跟他去聊，具体哪个项目前端没支持好时，他也说不上来。更多是对方对你有看法，而不是真的有什么问题。面对这种假压力时，搞清楚情况后，适当把耳朵堵起来就好了，不要太在乎他人的评价。
+
+补充说一句，所有资源短缺问题，实际上都是优先级问题。当业务往前发展时，无论前端还是后端，包括设计师等资源，从项目排期上看永远会是短缺的。关键点在于，一堆项目里，得区分出优先级。只要业务能有优先级排序，前端就一定能抽调人力去支持好优先级高的项目。
+
+带前端团队不要怕被投诉，问题上升来解决，往往对公司来说是好事情。这意味着可以一起从公司角度来重新盘下，哪些项目是最关键的，最需要提前支持的。优先级重新对焦清楚，对应调整好资源匹配，这从公司全局看是最优的。最怕的是遇到问题，不会彼此都往上上一个台阶去讨论。站高一点去看优先级，很多争吵都没必要。
+
+面对假压力，要让自己有定力。很早以前我挺喜欢写文章，有人就会说玉伯居然还有时间发博客，我只能说关你屁事。别人觉得你只要在做和工作无关的事，就会觉得你没好好干。认清楚这个是假压力就好。假压力也怨不得别人，往往是自己太在乎他人评价，去做到不在乎就好。
+
+极客时间：我大概能想象到你面临的这些压力，尽管有这些压力，支付宝体验技术部这个团队还是能顶住压力，去发现创新点，关键还能去验证，确实是很强的能力。你有想过为什么这个事情能发生在你的团队吗？
+
+玉伯：曾经思考过这个问题，现在总结起来，可以归结为三个因素。
+
+第一个因素是人的因素，前端团队里有不少多面手。其他团队在创新这一块，到现在都会很羡慕我们这一点。前端是可以通过 Node.js 去写后端，但后端很少有人愿意去学前端。后端团队如果要去做创新产品，绕不过去的问题是缺前端。然而对我们来说，我们自己可以学后端，能具备全栈开发能力，但后端学前端很难做出品质感。
+
+另外，体验技术部有设计师，你知道很多创新困境都是卡在缺设计、缺前端这两个点上。PD（产品经理）其实大家都不缺，因为大家都觉得自己就是 PD。在创新这块，我们有前端、设计师、Node 后端开发这三块人才，这让很多创新产品有了起步的可能。
+
+第二个因素，前端团队更容易培养出 PD。很多创新产品、技术产品都是前端或者设计师当 PD，虽然很多后端技术也觉得自己能够当产品经理，但是前端和设计师当 PD，我们优势比后端更明显，因为离用户更近，我们更适合往 PD 转，我们概率比他们高很多。后端往 CTO 转更容易，我们往 CEO 转更容易。
+
+第三个因素是，我们的团队文化非常鼓励创新。2016 年时，体验技术部做过一个内部创新机制，类似当年淘宝的内部赛马，我们叫“策马扬鞭”，搞过两次，不是由公司组织，而是我们部门自己去推动的。语雀、九色鹿、小钱袋等产品，都是策马扬鞭出来的。当然从上往下看，一定是这个公司是始终鼓励创新的，我们才能搞这个活动。创新文化很重要。
+
+综合起来，创新产品的孵化，需要有多面手人才，需要有 PD 潜质人才，还需要有创新文化。
+
+极客时间：策马扬鞭这事儿现在还在做吗？
+
+玉伯：没有继续了，就搞过两次。
+
+极客时间：是因为九色鹿和小钱袋项目吗？你前面聊到九色鹿和小钱袋项目最终都交给了别的团队。
+
+玉伯：跟这个有关系。当时 2017 年策马扬鞭出来了四五个项目，其实已经很耗精力。我们讲守正出奇，奇不能太多，如果每年都去搞的话，守正会出问题。同时当时也有一些外部的声音，大家觉得前端都不够，你们还在赛马，这种声音多到一定量级时，会对团队同学造成真压力。
+
+极客时间：你已经回答了体验技术部成长土壤从何来？一方面你和团队顶住了一些压力，并且拥抱创新文化，把大家放到具体的有意义的事情里，允许尝试，坚持长期主义。这种团队文化其实就是土壤。
+
+玉伯：团队给到同学一些信心、一些成长土壤是很重要的。我之前对这个话题没什么体感，现在越想越觉得重要。很多员工选择离开，跟他的直接主管是最相关的，看过一个数据，说一个员工离职，60% 的因素跟直接主管相关。
+
+薪资很重要，同等重要的是好团队、好主管。我聊过不少同学，是因为喜欢团队而留下来。大多留不下来的原因，是因为万物之中没了希望，能留下来的原因，则是万物之中留有希望。一个同学，如果能看到团队里有让自己变好的可能性，他往往就会留下。变好的可能性包括成长，很多同学对个人成长的看重大于钱。
+
+我们曾经做过一个问卷，问大家会因为什么原因而选择一个团队？我印象中排在第一的是个人成长，排在第二的是薪资，排在第三的是团队氛围。并没有那么多人因为钱这件事情就选择离开，但如果看不到成长的机会，往往分分钟就离开了。
+
+极客时间：我很好奇，你们团队做这个问卷的背景是什么？
+
+玉伯：问卷这事我们有持续在做。当年我有一个 OKR 是“让同学心有笑容”，这个笑容怎么衡量？就是看同学对团队的满意度。满意度的衡量，我们通过问卷来做。比较幸运的是，第一次问卷结果，体验技术部就做到 80 几分。
+
+极客时间：你觉得体验技术部为什么能够成为很多前端工程师，包括设计向往的团队？在体验设计，体验技术这块儿，支付宝体验技术部受欢迎程度数一数二，大家对这个团队评价非常高。
+
+玉伯：我觉得从外界来看应该就是三个点。第一个点，这个团队做了好几个开源产品，包括 Ant Design、AntV、EggJS 等，开源产品的影响力是业界对于有好感的关键因素之一。
+
+第二点，体验技术部比较喜欢对外分享，这也是一直坚持的团队文化。早期甚至会给大家设分享类 KPI，不是必须的，是加分项，做到了会考虑加分，要求同学不管是在内部还是外部都积极去做分享。这种鼓励对团队分享文化很有帮助。
+
+在 QCon 等很多技术会议里，都会有我们团队同学的身影，这相当于是我们团队的一批布道师。除了技术分享，我们也鼓励设计师出去讲，我们还自己开了一个 SEEConf 支付宝体验科技大会，也是延续这种分享精神。我们常说“当我们开始分享，也许世界什么都不会变，但是我们自己已然变化”，至今我们依旧非常鼓励分享。
+
+体验技术部受欢迎的第三点，我个人觉得是一直倡导的简单、自由、有爱的团队文化。我们一直推崇简单、自由、有爱，这三个词，会比公司的新六脉更受前端同学认可。
+
+简单最开始强调的其实是专业，因为足够专业，才能让事情变得简单。后来我们会把简单的含义，扩充为简单直接、有话直说等简单直爽的做事风格。新六脉里会强调直言有讳，直言有讳是挺好的一个倡导，但新同学很容易对这个词很懵，直言有讳，那我具体要忌讳什么呢？在我们自己的简单文化里，会把这个“讳”换用“说话和气”来诠释，这样大家就都能理解了，会更接地气。
+
+最后想说，体验技术部的受欢迎，离不开幸运成分。上面都是事后归因，可能只是相关性，未必有真正的因果性。
+
+小结时刻
+
+今天我们聊了一个关于团队创新土壤的话题，它一方面反映了一个团队管理者面临的压力，一方面也在观察一个管理者的努力。如何顶住来自各方的压力，为团队创造空间，如何让员工更有归属感？我所感受到的是，Leader 首先得有一颗强大且坚定的心脏，才能去分解压力，从而做出判断。
+
+最后想和你讨论的是，你所在的团队被其他协作部门吐槽过么，你们如何应对？欢迎分享你的想法，我们下期再见。
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/13行业内口碑第一的前端团队，如何打造文化.md

@@ -0,0 +1,99 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            13 行业内口碑第一的前端团队，如何打造文化
+                            上一节我们提了三个关键词叫“简单、自由、有爱”，这是体验技术部的文化。为什么体验技术部会受到大家的欢迎，除了技术强之外，还有非常强的向心力，我们想了解玉伯所带领的团队是如何践行自己的文化的，这一节我们就继续听玉伯的分享吧。
+
+
+
+极客时间：你是怎么理解团队文化的，体验技术部的文化有三个关键词嘛，简单自由有爱，可以讲讲这三个词代表的含义么？
+
+玉伯：谈团队文化，需要先去看一个更大的话题：团队管理。
+
+我们经常会说，管理就是管人理事，可以从业务、组织和人三层去看。业务涉及使命、愿景、战略、规划等等，组织涉及招育用留、排兵布阵、梯队建设等等，业务和组织都是很大的话题，我们这里不展开聊。
+
+除了业务、组织，管理还有很重要的一部分，就是人。人这一层，和文化息息相关，团队需要找到什么样的人，什么样的人在这个团队是被鼓励的等等，文化往往会涉及团队的价值观体系。
+
+回到体验技术部，简单自由有爱的文化倡导，更多是帮助团队在寻找一批类似的人，会逐步成为选人育人用人的标准，长时间去坚持，团队的味道就出来了。
+
+
+
+文化要落地，一定不能仅仅是口号。在体验技术部，伴随着简单自由有爱的，更在日常里被大家感知的，是下面的一些土话。比如“真实不装，用专业说话”强调的是简单文化，“要快，但不能急”强调的是长期主义等等。这些土话会在日常会议中被提及，慢慢就会影响大家的日常行为习惯。比如开项目评审会时，有些人不敢说话，我就会提醒“有什么不敢说的，用专业说话就好”，有些土话就会逐步变成日常场景里的一些口头禅，这样就能真实让文化落下去，变成日常点滴。
+
+再举个例子。我们职级是隐藏的，但新人进来时，面对职级可能比他高的人时，会不太敢说话。但在我们团队，会不断强调不是谁职级高他就一定是对的，你在这个岗位上一定有你的专业，你得把你的观点表达出来，不需要去顾虑其他。通过这种方式引导一两次之后，一个新人会受到团队的影响，逐步变得敢说。这就是文化的力量。
+
+极客时间：这让我想到，文化就在这些细节里，文化不是挂在墙上的。
+
+玉伯：对，文化就是日常点滴，日常的行为举止才是文化本身。之前 Lucy（彭蕾）有一句话被传得很广：战略就是客户价值，文化就是言行举止。这句话我之前不太理解，但是后来发现我们自己在做文化的过程中还真是这么回事，文化真的就是你的言行举止。比如说作为一个 Leader，在跟同学沟通过程中，如果每次都说“你来汇报一下”，那种文化就不一样，它传递的信号是一种严明的上下级关系。我们很多时候会说，我们开个会一起讨论一下，脑海里不太会有汇报这个词。
+
+举个例子。“简单文化”里还有句土话是“不要在毛坯房里雕花。这个土话的来源，是当时在做不少创新项目，设计师会去做很多精细化设计，可业务还明显处于 0 到 1 的阶段，这些精细化的设计就像在毛坯房里雕花。我说这不是折腾嘛，你设计得这么细节，花了很大精力，同时前端开发也要跟着花大量精力去实现，本来一起一周能完成的活，要因为雕花变成三周才能完成，可业务想法可能第二周就变了。该粗糙的要粗糙，不是所有阶段都要追求精细化设计的。这个背景下的心得，被总结成了“不要在毛坯房里雕花”，很多同学就记住了，同时会去思考，究竟当前产品是毛坯房，还是精装房。如果是精装房，可以好好雕花，但毛坯房没必要。
+
+还有一句土话是“静水流深”，这跟长期主义、愿等花开一脉相承。所谓静水流深，很多很深的水表面上是波澜不惊，但下面流得很快。很多事情，并不需要在聚光灯下，需要的是坚持去做有价值的事情，然后到了某个点才可能会体现出大价值出来，或者才能够跟某些河流甚至大海汇合。过程中如果太着急，老想翻腾浪花，那可能就做不出来了。这些土话，都是文化。
+
+再聊一句土话：“要快，但不能急”。急的是心态，强调做事的心态不能急，心态一急很多事情就会搞糟。要快，指的是要有整体规划节奏，要有条不紊、有节奏地去推进事情。在求快的整个过程中，要保持心不毛躁，心是平静的、稳的。这其实挺难，更多我们是通过这句土话，去提醒自己不要心急，这是用来反思自己心态的一个好工具。
+
+这些土话，会每年迭代升级，每一年都有增加或删减。比如说你看这个图里一些标红的“土话”，像“敢说真话，说话和气”，就是前年增加的。当时因为团队里的文化太自由、太简单，大家有时候就会跟合作方怼，因此我们老被投诉，我们就感觉好像这个文化稍微有点偏离初心。怼完合作方后，我们同学是爽了，但是对方同学就会觉得玉伯团队怎么这么有个性，怎么一个个都像长了毛刺一样？那段时间觉得非常不对，于是增加了“说话和气”这条土话，一方面会继续强调要敢说真话，同时一方面强调一定要说话和气，要有爱。“说话和气”挺有意思，最早是在八路军的三大纪律八项注意里看见的，这是当年军队的一条重要注意事项，非常有意思。
+
+通过土话来做文化，这是我在做团队文化时，觉得最有意思的一个点。这在很多管理书籍里面是看不到的。大家可以尝试用用，会有不一样的收获。
+
+极客时间：这种标语很多公司也都会做，但也许就停留在宣扬标语上，但听你也说了很多实践案例，感觉你们是在日常中大家用实际行动去说明文化到底是什么，可以这样理解么？
+
+玉伯：对的，更多是靠日常的会议、讨论等各种环节里去强调的。
+
+每个管理者在日常中的以身作则是关键，还有一个很重要的点是，我们每个季度会有一个叫“海阔天空”的全员大会，在这个会上，我会每次都强调下团队文化，特别是对增加或删减的土话。同时在新人圆桌等环节，也会带带货，把一些文化理解通过案例传递给新同学。
+
+极客时间：我突然有这样一个感受，你们所说的文化很多时候来自团队中真实遇到的痛点，解决这些痛点的办法就是提倡的文化本身，你们把它总结出来，在各种场合去重复，最终把它沉淀为一些词，那另外，会不会有这样一个现象，因为团队同学想法太一致了，会导致看不惯别人的东西。会有这样的感受么？就像别人说过的“怎么感觉玉伯团队的人像长了毛刺一样”。
+
+玉伯：这个现象也很有意思，我去研究过，这种现象叫做文化的反噬。
+
+比如过于强调简单和自由，很多 Leader 或同学潜意识就会偷懒，比如遇到困难时，会说“怎么办呢？我就是这么一个简单的人”，会用文化来帮自己开脱，这就是文化的反噬。
+
+意识到每个词都有两面性时，我有开始思考，究竟怎样的文化倡导是好的。后来就会有意去研究组织文化的书籍。很幸运很早年就看到了一本很好的书，叫《奈飞文化手册》，中间谈到了自由，但提法是自由与责任。这个提法，让我恍然大悟，突然就知道如何去让简单自由有爱更合理了。
+
+具体做法就是，把简单、自由、有爱当成三枚硬币，硬币都有正反面。正反面的存在，共同组成了一枚硬币。因此当年仔细研究后，会把简单的背面刻上了专业两个字，自由的背面是责任，有爱的背面则是行动。具体含义也很好理解，比如简单的背后一定不是复杂，我们花了一点时间求证，最后发现专业才是简单的背面，因为足够专业才能把事情做得简单。自由的背后是责任，强调的是敬畏之心，是责任意识，特别是在支付宝，支付和金融，对责任心的要求很高。有爱的背后是行动，因为不能老谈有爱，但啥行动都没有。这也会落到一些管理的要求上，比如管理者如果想让团队同学工作更快乐一些，这个目标的达成，一定是看具体行动的。
+
+通过硬币的比喻，就把原来的三个词，扩充到了互为关联的六个词。大家也很容易记住，同时看问题会变成更综合。经过这次升级后，文化的反噬就会少很多。
+
+文化往往会显得很虚，哪怕转化成很多土话后，依旧很容易被看成是虚的。文化真的要落地，必须要有一些非常实在的具体的措施。
+
+比如有段时间，我会要求每个 Leader 每个月要跟下面至少 5 个同学面对面沟通一次，沟通时一定要关注到同学有什么困难，关注到同学可能希望获得什么样的帮助。这个具体要求，在做的是“有爱”这条文化的落地。一个主管不能满眼只是事，同学有什么心结，遇到了什么困难，如果一个主管什么都没感知，很多时候是带不好兵的。
+
+极客时间：你们一些会议、活动的命名也挺有意思的，比如海阔天空、策马扬鞭这类词。之前咱们聊到做产品内部需求评审的时候，你们还有一个叫 KK 制的流程，“KK”代表什么，需求评审怎么运作，可以展开聊聊么？
+
+
+
+玉伯：“KK 制”是语雀在用的项目管理机制，K 就是 King 的意思，K 就是小王，KK 就是大王。大王是指业务负责人、产品负责人、技术负责人和运营负责人。语雀里面分不同产品线，一条产品线会有一个 King 在负责的，他会去组织这个产品线的需求讨论和评审。在正式研发前整个流程分几个环节，叫“QT-QD-FD”。
+
+第一个环节叫做 QT（QuickTalk），假如我们要做某个功能或者来自用户的某个反馈要变成需求，负责的人会先把文档（包括背景+解决方案）写好，快速讨论这个想法要不要去做。会一起确认这个需求是不是靠谱的，QT 环节有时候会来来回回好几次。
+
+QT 结束之后，会有一个快速决策环节，叫做 QD（Quick Decision），需要确定这个需求究竟是否要做。这个时候除了小王之外，大王也会来参与。我们需要判断 QT 讨论出的版本，回答出两个问题：该不该做？是不是现在做？包括是否符合我们产品定位、是否真的在解当前的业务痛点，以及优先级怎么样。
+
+QD 之后第三个环节是 FD（Final Decision），要做详细评审了。因为 QD 很多时候只是一篇文档，是一个非常粗的解决方案，还没有设计稿，PRD 也没写，很多地方还只是一个想法。到了 FD 的环节， PRD，设计稿都要具备的。一般 FD 一次过关的很少，也会反反复复不断探讨之后 FD 才能通过。
+
+在 FD 通过之后就开始进入了常规的研发环节，研发环节之后测试上线。然后在上线之前我们有一个特色，叫做 Showtime，一个全民测试环节，把大家都调动起来，就是快要上线了大家一起来测一测。会测出一些 Bug，修完再上线。
+
+极客时间：这个 King 小王一般是什么样的一个角色来承担？
+
+玉伯：目前来说会以产品经理为主，之前技术人员也尝试担当过，会鼓励同学自主担当。我们不太看角色分工，强调的是用专业说话，不是看谁的声调高，而是看谁说的话有道理。
+
+极客时间：这几个环节里面你会主要参与哪几个？
+
+玉伯：我其实核心参与的是 Final Design，有时间的话会参与 Showtime。我更关注的是上线之后用户的反馈。
+
+极客时间：这个 KK 制只在你们团队还是说蚂蚁都用这一套？
+
+玉伯：这是语雀特有的。因为公司那套流程是特别规范的，比如有 PMO 这个角色，专门做项目管理，语雀没有，所以就设置 K 来做项目管理。语雀是一个全功能型的创业团队，是完全自闭环的。从运营、产品、设计师到前后端，这些角色全在一个团队，这套规则是这个团队自己找出来的。
+
+我们总得去找一套流程，最早期也去试过公司那套流程，发现不适用。比如说支付宝的项目流程里面有 CP0、CP1 的说法，就是设置 Checkpoint 检查点，这些检查点需要有业务一号位、技术一号位、质量一号位达成一致才能通过，这个流程非常重，如果套在语雀身上，并不合适。
+
+后来我发现其他团队也在借鉴我们的做法，他们也开始有 FD 环节。内部有不少团队对语雀怎么从 0 到 1，怎么创业很感兴趣。我在内部做过一些分享，慢慢就会把一些做法传播出去。
+
+小结时刻
+
+今天我们聊了打造团队文化的话题，策马扬鞭、海阔天空、KK这些词让我印象深刻，总结起来，最重要的一句话应该就是“文化就是日常点滴”。最后想和你讨论，你们的团队文化是什么？你认可么？欢迎在评论区留言，我们下期再见。
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/14管理能力提升：曾经影响过的书籍和启发过我的人.md

@@ -0,0 +1,131 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            14 管理能力提升：曾经影响过的书籍和启发过我的人
+                            前面玉伯分享了管理者的职责，如何打造团队文化等话题，今天我们继续围绕管理话题，看看在管理这条路上，他是如何学习和实践的。
+
+
+
+极客时间：你现在带了几个不同的团队，体验技术团队、小程序团队、语雀团队，有的是平台技术，有的就是业务技术团队，从管理上会有不同吗？会用不一样的管理办法么？
+
+玉伯：这三个团队都不太一样。体验技术部是综合型团队，有业务支撑部分，也有基础设施部分。小程序团队是基础技术型团队，更偏重技术本身的发展。语雀团队是内部创业型团队，各种角色会更多。
+
+业务支撑型团队，要懂业务，要对业务更理解，有一个基础考核是业务支撑效能，需要把业务支撑好，保证重点项目不延期。
+
+基础技术型团队，要对技术本身有认知，要热爱技术，知道技术对业务的价值在哪，同时要对技术产品化有经验，能不断带领团队做出一个个技术产品，服务好业务，能说清楚价值所在。
+
+从表面看，这两种团队类型，对管理者的要求不一样，但抛开表象看底层又是一样的。比如都需要对需求做出的判断，都需要在某个领域有专业积累，这个领域专业积累，可以是某个技术领域，也可以是某个业务领域，同时还都需要管理者有规划决策能力，能看见未来，能面对各种不确定性时，做出取舍权衡。很多能力上，是相通的，最终都需要能拿出业务成绩。
+
+极客时间：考量是否能拿到业务成绩，这很有意思，如果做技术的同学都这样想的话，对于职业发展方向，其实思路会更广一些。那么做业务需求的人和做更底层基础技术的人，彼此间是如何认知的，可以说说你的观察么？
+
+玉伯：做基础技术的同学，往往做着做着，想去做业务。做业务支撑的同学，往往做着做着，会想去做基础技术。这就是一个围城，城外的人想进去，城里的人想出来。
+
+回到一线同学，这个围城带来的困惑非常常见。技术人对自身价值认知的不同，到现在为止都是一个普遍存在的问题。但这个问题很难解，靠沟通是解不掉的。体验技术部的做法是，尝试每隔半年，如果有做业务支撑的同学想去做基础技术，且也有这个能力的话，那就调整一下。反之也一样，让想做基础技术的同学，能选择去做做业务。
+
+调整完成后，往往能让同学有完全不一样的感受。比如调整去做基础技术的，会刚开始很兴奋，但很快会发现，做基础技术也有一堆 bug 要改，也有各种项目排期，跟在业务线接需求是一样的。
+
+这就是个围城。做基础技术的，也有很多同学觉得基础技术很难拿 3.75 绩效，基础技术很多是长周期，有同学就等不及，觉得做业务更容易拿到结果，公司很多奖项、聚光灯都是放在业务上的。每个基础技术方向，往往要做到一定阶段才会被看见，大部分情况下会在边缘，别人看不见，各有各的难处。
+
+调完之后，最大的一个好处，是可以让做基础技术的和做业务支撑的同学，能彼此互相理解了，能真正感受到，原来都挺难。有些同学，能在调岗后，更善于去观察别人，同时开始更了解自己，知道自己原来更适合做业务，或者更适合做基础技术，自己的心就能安定了。心的安定，需要亲身去试试，很难通过沟通来解决。
+
+极客时间：还有一个关于管理能力的问题，很多技术同学他可能不愿意做管理，或者做管理也是勉勉强强被任命推上去才去做的。你自己的体会是什么样的呢？
+
+玉伯：技术人应不应该去做管理，我曾经也纠结过，担心做管理后很多事情会被管理工作耗掉，导致写代码的时间减少。这时团队里一些很优秀的年轻人，天天在写代码，天天在学新东西，你可能就会恐惧自己的技术能力跟不上。这是一个很现实的问题。技术人如果转做管理，这中间必然会有所失的。
+
+目前我自己的心得就是，很多时候还是要回到对自己的认知，所谓认知就是要判断自己究竟更适合写代码，还是适合做管理。但确实，很多时候一线同学第一次做管理，是被任命的，往往缺少充分沟通的过程。
+
+在和一线同学沟通时，你问他要不要带个团队，他说不愿意，这样的人也有，但是极少数。像这种同学，我觉得是很难得的，他清楚自己的能力和长处。也有很多同学尝试做管理之后，发现不适合，然后再回到原来的角色，这样的情况也正常。
+
+但是整体来说，当一个同学变成管理者之后，只要他真的愿意往前迈一步，是可以具备管理能力的。我觉得可能有80%的成功率。往前迈这一步，就是逼迫自己走出舒适区。这个过程中，涉及如何提升管理能力。目前大部分互联网公司都没有什么培养体系，绝大部分技术管理同学主要都是靠自学成才。
+
+极客时间：你还记得参加过的培训么，你觉得参加过的培训有用吗？
+
+玉伯：很早时期参加过一些培训，觉得有用印象深刻的很少很少。现在还记得的，是曾经有个台湾讲师，来讲关于沟通交流的课程，核心是有个盒子模型，要沟通交流，需要双方能走出盒子（out of box）。当时我比较敢提问，老师对我印象很深，我对他印象也很深。
+
+“out of box”是在讲沟通协作时，人必须打开自己，必须要有人从盒子里走出来，并且要把对方也从他的盒子里拉出来，然后再对话。我经历的培训只有这个课程让我印象深刻，而且对自己学会如何沟通对话感觉很有帮助。其他很多课程，感觉都是自己通过各种书籍里就已经知道的道理，很少有具体教会你怎么实践的。
+
+极客时间：你觉得自己是自学成才类型的，那么你在管理上自学成才过程是什么样的呢？
+
+玉伯：有两个路径，一是看书，一是实践。我会定期去看很多管理相关的书。到目前为止，对我影响最大的一套书是德鲁克的管理学书籍，德鲁克是人文和管理大师。我最近还在重刷他的一本书，叫《卓有成效的管理者》。德鲁克对我影响很大。
+
+一本上个世纪写成的书，很多观点放到现在来看，仍然感觉每天在公司里发生。这本书里提到很多管理者容易踩的坑，比如说很多公司都会做人才盘点，盘完之后都会针对每个人做一些人才改进计划，录入到系统里，或者是用一个文档存下来。但这件事，在录到系统里后，往往就没有后续了。等真正要做一些人事决策的时候，很少有管理者反过来去看当初这些人才盘点里的想法。
+
+德鲁克讲了一个案例，谈到有一个公司，CEO年纪轻轻意外去世了。这位CEO很厉害，在位时制定了很多公司的政策方案，包括怎么用人，包括人才盘点等整套东西。他的接任者，是之前公司的第二号人物，比原来的 CEO 年纪要大，在公司时间更长，他从没想过自己会当一号位。所以当这个年轻CEO故去后，他还挺苦恼的，应该怎么办？他做了一个很有意思的决策，就是看之前的人才盘点，并根据人才盘点里的建议，去推动执行。他每天会花一个小时去看这些曾经的档案，看的过程中会打电话给相关 Leader，问当初人才盘点完成后，计划补充或替换某某的建议，有没有具体落地实施。相关 Leader 一接到这种电话时，开始恐慌，想着“CEO天天给我打电话，看我当年制定的策略有没有执行”。于是因为CEO这个举动，整个公司大概花了一年后焕然一新，然后他就成为这个公司最伟大的CEO。
+
+这个案例讲的是一个大家都懂的道理：行动改变一切。但真正能做到的，凤毛麟角。看书的过程中，会时常汗颜，发现里面讲的很多错误自己曾经也犯过。看书是一方面，但做管理不能停留到书本上，最终要落实到行动，管理者更大的成长就在于实践。
+
+比如说，最简单的管理实践之一，就是一对一沟通。这在管理上是非常重要的东西，但这个东西其实说起来很简单，就是作为一个 Leader，你得跟下面同学保持一定频率的沟通。你不沟通的话，其实永远不知道这个团队真实处于什么样的状态，或者你的感知很容易被一些传到你耳朵里的声音给蒙蔽掉，你不会知道一些真实的声音。一对一沟通我觉得是管理日常中很重要的部分。
+
+另外，德鲁克《卓有成效的管理者》里面还有一点对我影响也很大，就是他在解释“成效”是什么。成效就是成果加效率。他有一个非常强的观点，就是成果永远来自外部。你在团队内部一对一沟通当然很重要，但是你如果永远做内部沟通，你就最多只能把自己的团队整理得很好，可能会提升一点效率，但是无法产生成果。
+
+之前我也觉得把自己工作做好可能就好了，但是最后发现根本不是这么回事，管理者在保证内部稳定成长的情况下，更多的精力，最好80%以上的精力应该是向外看，去跟你的合作伙伴、客户、用户去交流，在这个层面上才会产生真正的成果和效益。
+
+我自己在管理方面的成长，我特别感谢的就是德鲁克。
+
+极客时间：刚刚说你看德鲁克的书，里面讲到的很多管理者会犯的错误你都犯过，具体指哪些，可以举个例子么？
+
+玉伯：好多例子。比如德鲁克说要用人所长，核心要看这个人他能不能成事，他的缺陷你并不需要去在乎，甚至你都可以不知道。这个观点让我反思自己以前的想法。
+
+比如说我六七年前要去提拔一个 Leader 时，会综合考虑这个人的方方面面，最好是技术要好，又懂业务，同时人很正直、脾气好，沟通能力也强。各方面希望他是一个很好的人，当然肯定有这样的人，但是很难找，对我是个挑战。而且我发现等要给他打绩效或者是做评价时，管理者很容易去看人的短处。包括现在很多刚做管理者的同学也会犯这个错误，经常会说“你在某块做得挺好的，但是……”，这个“但是”后面就跟一句话也行，很多人“但是”后面能说出个一二三四五条，这就不是用人所长了，而是盯人所短，非常不好。这种错误，很多管理者都会犯。
+
+用人所长，需要有意识地去看一个人的核心优势所在，去想某件事情让谁去做最有可能做成，以这个方式去想，能少掉很多纠结。我早期会说扬长补短，但是到后期我们只说扬长避短，甚至扬长就好了。
+
+比如说有些岗位就是要有冲劲儿的，甚至就是要说话很简单直接的，而不是说有高情商沟通能力的人，那我就去找这个说话直接的人来干。也许他在沟通上会跟对方产生矛盾，但这没关系，他能把问题暴露出来，反而可能推动整件事情快速往前推进。
+
+用人所长，需要懂得什么样的事情需要什么样特征的人才，同时也需要看懂每个 Leader 的特质，这样才能把合适的人放到合适的岗位上去，让大家的才华都能尽可能发挥出来。
+
+极客时间：你现在和一线同学的沟通，除了一对一这种形式之外，还有什么通道吗？
+
+玉伯：好多。现在更多的沟通其实都是基于文档的，我会直接点赞回复，大家也习以为常。比如说直接回复同学的各种文档。这也是我们团队的一个习惯，好像因为我这么做，所以下面同学也会这么做，大家会比较习惯这种方式。有些新同学刚开始会不太习惯，感觉 Leader 回复了会很紧张，但隔上几个月，发现这就是团队的风格，很正常，也就习惯了。
+
+极客时间：现在很多年轻的新同学加入一家公司，确实特别有斗志，也特别有热情，但有时候领导会觉得他某件事做得没那么好，但他自己觉得特厉害，这种情况你怎么去纠偏，你会怎么帮助他更踏实下来？
+
+玉伯：这个情况确实存在，团队里确实有不少同学，特别是新入职的、学校又好的同学，他可能从来没怎么经历过挫折，会对自己的要求和期待都很高。
+
+经常出现的一个情况，就是这位同学会给自己打很高的绩效。比如打绩效都不是打3.75，而是直接给自己打4分。这个时候我觉得在目标设定和绩效评估这两个环节要非常严肃地跟他聊，我会很正式地约一个会议，叫上他的主管、HR，还有我，几个人一起沟通，说明白为什么绩效结果并没有达成心中的3.75甚至4。
+
+对这部分同学我们定目标的时候可以拔高一些，这样的人很优秀，对自己有要求，可以让他做一些更有难度的事情，同时在绩效评估时，给到客观合理的分数。那句老话还是挺对的，叫做没有拿过3.25的人生是不完整的，当然这个话现在很少说了，因为任何人的人生都是完整的，所以这句话是一个有时代感的东西，目前很少这么说了，更多是说人要经历过一些低谷才会成长得更快。对这类同学，要求要高，同时评估要客观合理。
+
+极客时间：还有一类同学，可能和上面这种不太一样，他们也很优秀，做事情也很精益求精，但他们给自己的评价没那么高，或者不敢自己争取更高的机会或者待遇，有没有遇到这种情况？对这种同学你会怎么办，怎么样激发他、鼓励他大胆地去争取自己应该有的机会和权益呢？
+
+玉伯：这种同学确实也有，比前面那种少一些，一般来说这种人对自我要求很高，而且谦虚到老是给自己打3.5-甚至3.25，也有这类同学。
+
+对待这类同学，日常一定要给到一些肯定、鼓励，这样同学在日常就能感受到。但单通过沟通很难改变同学对自己的看法，这时更考验的是 Leader，作为 Leader 如何帮助同学提升自信，Leader 需要更主动为同学争取权益，对同学多些肯定，让同学对自己的认知慢慢能来回客观合理的水位。
+
+这些情况，反映的都是人性问题。佛教里谈人性最基础的就是贪嗔痴，贪是什么？就是你想要、想得到，或者想靠近的东西。嗔是什么？就是你不想要、想远离的东西。痴是什么？并不是痴情的痴，而是白痴的痴，就是你也不知道想要啥，你也不知道自己喜欢什么，这种叫做痴。
+
+在佛学里，有十二轮回图，会用动物形象去比喻贪嗔痴。贪一般是用鸽子去描述，寓意就是鸟类吃东西很贪，这也是为什么很多广场里面会提醒游客不要喂食，因为鸟会一直吃下去，会吃出问题，鸟在佛教里代表着贪。嗔一般形象是蛇，人一看到蛇就会很容易心生恐惧，想远离，这个就是嗔。痴的形象一般是用猪来表示，猪看起来很笨，成为了痴的代表。
+
+回头再看管理，会发现像刚才的分析的两类人，一类是自我认知比较高，一类是自我要求很高。第一种自我认知很高的人，往往是嗔这块有问题，他可能从小被捧着长大，对不认可的东西会默默远离，他看到3.25就是不喜欢，内心里就是觉得自己很优秀应该打3.75，他看起来好像是自信满满，但实际上我觉得很多时候是在嗔的层面上没有经受过恐惧，也许他不知道怎么面对恐惧。当他真正经历过一些低谷，敢于正视内心恐惧的时候，就克服了嗔，后续就能更好地认识自己。
+
+第二种是自我要求很高的人，很多时候是因为从小缺少关爱，他得到的认可是有些欠缺的，所以解他的困境，就是在日常中慢慢让他知道自己原来不是那么差，其实能力很强。但这个需要时间，而且还挺难改的。在心理学中，弗洛伊德说，人的过往经历对现在的你影响很大，这个我其实不大认同，我还是提倡阿德勒的理论，就是未来决定一个人，你对未来的一些憧憬会让你发生改变。自我要求很高的人，在管理上，可以适度激发他的“贪”并满足，让他能更自信一些。
+
+对于痴的人，我不会招进来。但是痴这种情况，在工作中也经常能发现，特别是跨领域沟通时。有些团队互相吵架，就是因为互相对彼此是痴的状态，我不理解你的领域，你不理解我的领域，这个时候核心就是要打破痴的状态，去了解彼此的领域是怎么回事，把互相的痴解掉，就会少掉很多矛盾。
+
+不论是做产品还是做管理，我觉得必须要“懂人性”，还是蛮关键的。我对张小龙印象深刻，是他的洞察能力很强。很早以前有一次去广州参加微信公开课，当时微信有个同学就带我进去参观，去到张小龙办公室门口，当时大概 11 点多，他还没上班，我们就在那里拍照合影。拍着拍着感觉好像有一个人在看我们，那个人就是张小龙，我们在那里摆拍时，他已经走过来了，但他看到我们在拍照，他就默默站在那里不动，等我们拍完之后才过来。这种细节里，折射的也是张小龙的懂人性。
+
+懂人性这个词很容易被误解，觉得是一个贬义词。但如果你想成为一个好的管理者，想成为一个好的产品经理，对人性的洞察是非常关键不可或缺的。
+
+极客时间：在管理这块，德鲁克给你影响很大。那在你身边的人呢，有没有对你在做管理、带团队、做文化这些方面产生过影响的人，或者你可以从别人身上学到的可以去借鉴的东西？
+
+玉伯：说起来，对我影响最大的一个人，是当时蚂蚁的CTO鲁肃的影响很大，体验技术部的成立跟鲁肃也有关系。他对我的要求就一句话：蚂蚁前端遇到任何问题，玉伯你要搞定。他给了我一种放养式的信任，或者说是托付式的信任，会让我觉得自己责任很大，从而愿意非常独立自主地去做好体验技术部。
+
+鲁肃还有一个对我影响很大的点，是谦卑。鲁肃真的是一个谦谦君子，永远保持一种“空杯心态”，他的空杯能从行为上体现出来。举个例子，鲁肃还是我主管的时候，我每年的规划要向他做汇报。这个时候，鲁肃会认真在听，同时拿个本子认真在记，会跟我说，前端这块玉伯你是专业的，我不懂，玉伯你给我讲讲这块是怎么回事。非常谦卑。
+
+但同时鲁肃又很专业。他的专业在于我讲了一个小时之后，他记了很多点，然后他真的在接下来半个小时能给到我实打实的建议。他会从过往经验里，通过横向类比的方式给我一些帮助，有非常具体建议，比如某个方向你要再考虑一下谁的意见，某个点要怎么去想，他能够给我一些有帮助的建议。鲁肃对人的谦卑又专业的态度，让我非常佩服。
+
+在管理这条路上，我也是从点滴日常里向他学习。我曾经说话有些结巴、很紧张，后来鲁肃给我推荐了一本书，里面讲的也是管理里面很有名的一个案例：人才分两种类型，一种是善于说的，一种是善于写和读的。鲁肃会跟我说，玉伯你别紧张，你回去给我写份邮件吧，你是能表达好的。他通过这种方式引导我成长。我也是因为这个原因，一直保持着良好的写作习惯。
+
+还有一个人对我影响比较大，就是行癫。我和他接触后发现，原来一个做技术的人心中，是可以如此满眼是产品。他坚定了我一边做技术一边做产品的信念。他是典型的从做技术到做产品，到带业务的人。我看到一个人做事原来可以这么投入，行癫那种热情和那种做事的决心，对我影响很大。
+
+小结时刻
+
+最后，做一个延伸分享，关于玉伯带领的体验技术部对管理团队的要求，通过图片方式展示给你，包含了“体验技术部管理共学手册”和“管理者的六不要”，也欢迎你在评论区交流对管理培训、管理学习方式的看法，我们下一讲再见！
+
+
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/15从浆手、掌舵人到兜底人，管理者进阶的三阶段.md

@@ -0,0 +1,95 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            15 从浆手、掌舵人到兜底人，管理者进阶的三阶段
+                            从淘宝到支付宝，从阿里到蚂蚁，从带领几个人到带领几百人，玉伯管理的团队在不断变大，他从自己的经历出发，总结了管理者进阶的三个阶段，聊了聊他对这三个阶段的理解。
+
+
+
+极客时间：你带领的团队从十几个人到几百个人，在团队逐渐变大的过程中，对管理的要求也是不断提高的过程吧？会有什么不同？
+
+玉伯：团队从小变大的过程，对管理者的要求也在变化。我觉得以我的经历和经验，管理者成长可以分为三个阶段。
+
+第一个阶段就是开始带一个小团队，可能七八个人或二三十人，这是第一个阶段。这个阶段作为技术管理者，最核心的能力是以身作则做表率，你得冲在前面，你做事情的方式对目标达成有直接影响，而且你往往就是主力之一。
+
+这个阶段如果就开始搞管人那一套，我觉得会很难管起来，更需要做的就是身先士卒、冲在一线，跟同学们在一起。我非常建议一线 Leader 坚持写代码，一旦 Leader 不写代码，就容易脱离真实情况。
+
+第一阶段要保持具象的体感，对重要的问题要能身先士卒去做。
+
+极客时间：这个阶段是不是管理成分比较少，管的是哪个方面？
+
+玉伯：也有管理的部分，往往和事情融在一块。比如如果带的团队是做业务支撑，你得熟悉这个业务线当前重要的项目是哪几个，以及在当下遇到什么样的技术难点或人员缺失。一方面作为一线 Leader 要冲在前面，另一方面 Leader 要很清楚团队里谁的战斗力比较强，如果要调整人员，比如说要从 A 项目调整人去支撑 B 项目的话，你得知道怎么补位。
+
+这个阶段的管理是在做一些非常具体同时价值非常明显的事情。技术同学刚转做管理时，这个阶段也是一个缓冲期。这个缓冲期必须要保持住写代码，甚至写代码的时间要超过 50%，同时兼顾做招聘、绩效、项目安排等管理事宜。
+
+这阶段程序员的特质会更多一些。
+
+管理的第二个阶段，就是你的团队可能到四五十人甚至上百人了，下面开始有二级管理者梯队。这时对管理者的挑战会快速变大。
+
+其中有一个挑战，就是一下子不知道怎么做。因为看起来是往上走了一步，但实际上会感觉自己被架空了，一下子好像被拎了起来。
+
+这时你会顾虑，要不要继续直接冲到一线，跟一线同学一起继续写代码。在一些重点项目中，Leader 依旧可以继续写代码。但一般这时，也容易暴露出管理问题。你很容易绕过二级管理者，直接跟他下面的一线同学去写代码，你会越级，会让你下面的 Leader 感到困惑。这中间，什么可为，什么不可为，如何把握好度，需要沟通讨论清楚。这个阶段，管理者需要去真正理解管理书籍上说的“学会授权”这四个字。“学会授权”四个字，看似简单，要做到，并不容易。
+
+学会授权的管理能力上，最容易犯的两个错误，一是要么太松，一是要么太严。太严就是事无巨细，但凡下面做什么，都要向你汇报，搞得下面的 Leader 很痛苦。太松好听一点是放权，然而换言之，就是不管，是放羊式管理，长期放羊是会出问题的。
+
+在松和严之间，一定要去找到适合团队的度在哪。程序员很多时候，很容易去追求确定性，会问那我到底是放权 30% 还是放权 50% ？一旦理工科思维，问出百分比时，就没法回答了，因为管理关于人性，管理是门艺术。面对不同的事情，授权的松紧是不一样的，变量很多，特别是涉及人。人往往是管理里的最大变量。拿人的性格来讲，如果下面的 Leader 性格比较开放，你紧一点他可能也不会有太多顾虑。但如果下面这个 Leader 本身比较敏感，这个时候你松一点会让他更舒服。需要根据人的不同特征，把握好授权的方式方法。管理最核心的，是把人激发出来，有干劲。
+
+再谈谈管理的第三个阶段，可能带几百人近千人，这时不光有二级梯队，也有三级及以上梯队。我自己是最近几年团队变得很大，刚带五六百人时，几乎每天都会去想怎么才能带好大团队。我当时的感受是，一方面还是会有架空感，另一方面又会变得特别忙。
+
+架空感来源于，大量事情，没有自己也都能落地，会觉得自己是多余的。公司里其实没有谁是不可替代的，没有你，所有事情也都能运转，项目也不太会因为你而延期，这时就会有架空感。另一方面，发现自己很忙，有很多会议，无论是兄弟团队的、业务方的，还是自己团队的，会收到很多会议邀请，日程里被排得满满的。
+
+这时，作为 Leader，往往需要停下来，仔细思考，重新去寻找到自己的核心价值点在哪。
+
+第三个阶段，说起来也很好玩，德鲁克又拯救了我。重读《卓有成效的管理者》，里面有个最基本的观点是：作为一个管理者，你一定要掌控自己的时间。有架空感还觉得很忙时，其实面临的问题是：我究竟应该去做什么事情才更有价值？这个事情得从目前公司的大环境出来，要从自己的核心能力出发，去结合具体团队情况，去思考得更清楚。架空感，是因为自己核心能力没有被充分用起来，没有持续产生价值，这时就容易有架空感。忙，是因为没有想清楚哪些会议是可以不参加的，是没有找到自己的关键发力点。
+
+其实不仅对于管理者，对所有同学都是一样的，你唯一拥有的其实只有时间。想清楚自己的时间应该花在什么地方，并且真实去做到，这就能走出第三阶段的管理困境。
+
+无论身处哪个阶段，作为管理者来说，如何更有成效，最终都是回到自己的时间应该分配在哪些事情上。我现在的做法是分两步走，第一步是基于现状理清楚我究竟应该主抓哪几件事情，在年初做规划时，确定几场大战役要打，那这几场大战役作为管理者就要盯着。当战役进度有延后的时候你要问为什么，当一个战役遇到困难时，你要为它寻找一些外部帮助、一些资源，解决掉危机。具体去做关键的事，就不会有架空感。
+
+但一个 Leader 在做规划时，有个很容易犯的错误，就是没有取舍，或者说他想要照顾团队所有人的情绪。我曾看到有 Leader 在团队大概一两百人时，他下面有几个小团队，每个团队都有自己重要的事，结果他的年终规划就变成了汇总，他把每个小团队的规划汇总起来，面面俱到，尝试去照顾所有一线 Leader 的情绪，这种规划是很糟糕的。
+
+学会不用照顾所有人的情绪也是一个课题。因为在一个团队里，不是所有人都能参与大的战役，总有人不在这几大战役里。最近有一首歌唱得挺好：谁说站在光里的才算英雄。很多 Leader 在早期是不太敢在规划里大胆取舍的，规划往往会做得四平八稳。四平八稳往往会导致团队看似和谐，但时间一久，就会缺少锐度，同时人员会慢慢冗余。该做的加大投入，该舍的大胆说出来，这需要 Leader 具备说出来的勇气。作为管理者，不要指望每个一线同学都理解。如果大家都理解的话，往往就是一个平庸的管理者。
+
+极客时间：人的成就感要么就来自于自己做成了一件事，通过自己拿结果，要么通过别人拿结果。通过别人拿结果也就意味着你有个团队了，很多人说在这个阶段，管理者应该把注意力放在你的团队有多厉害，你要成为团队的后盾，全心全意为团队付出，这样来找到自己的价值感。这个过程其实也是一个自我心理说服的过程。你有过这样的想法或者阶段吗？
+
+玉伯：马云曾经分享过一个观点，叫“用人成事”，这种观点需要站在 CEO 的高度去用人，对更大管理者来说，要谨慎“用人成事”。
+
+更多管理者所处的阶段，更需要的是“因事用人”。无论做组织设计还是定年度目标，一个基本出发点，还是要回到事情本身。德鲁克强调的也是因事用人，会很强调根据事情、目标去用人所长，通过这个方式把人的能量尽可能发挥出来。因事用人的过程，就是在成就他人。
+
+马总所说的“用人成事”，可能是管理的第四个阶段，是更大的 Leader 思考的方式。体验技术部的日常管理中，更多还是“因事用人”。
+
+极客时间：刚刚讲了管理的三阶段，有一点挺有感触的，之前我们一般讲怎么做管理都会讲管理者怎么跟这个团队去交互，怎么去管下面的人，但你其实分享了一些关于管理者心态，关注自我状态的内容，比如从程序员刚转管理，转变身份的不适感，架空感等等，这些是正常的。
+
+玉伯：很多时候我们说管理就是管人理事，我觉得还缺了一个维度，就是管理自己。无论在管理的哪个阶段，有一条暗线就是，要提升自我管理能力，这个非常重要。
+
+特别是到管理的第三个阶段后，自我管理能力很关键。比如每天要开很多会，都说需要你参与，这时候谈不上你控制时间，而是会议时间在控制你，你就得提升判断事情重要性的能力。
+
+我有个前主管，他有个习惯，会给自己定些原则，比如说，所有要求他去做发言的会议，他一律拒绝，因为一般让他发言就给十几分钟开个场或做个总结，很无聊。他的原则是，让他去的话要最少给 40 分钟，因为只有这样，才能真正分享出有用的东西。当你在可控范围内定一些原则时，别人会知道你的原则所在，慢慢时间就会回到自己手里。
+
+每次别人给我发会议邀请，我之前都是习惯性接受，但现在我学会了明确拒绝。最开始会觉得直接拒绝是不是不礼貌啊，但点过第一个拒绝之后，你会上瘾的，你会发现其实不去也没啥。我现在拒绝的会议至少占了一半。
+
+作为管理者，一定要掌控好自己的时间。
+
+极客时间：在管理三阶段里，每个阶段每个管理者要发挥的作用是不同的，有一个递进过程，能不能再抽象一下？每个阶段管理者应该发挥的重要作用。比如说第一个阶段管理者其实有点像一个冲锋者的角色。
+
+玉伯：可以用“划龙舟”来打个比方。
+
+第一个阶段的管理者，他也是划船的主力之一，甚至是最有力气的那个人，但同时不光自己划船很牛，还得跟团队的节奏匹配上，这样船才会走得比较快。第一个阶段的管理者，是桨手之一。
+
+第二个阶段，管理者有点像站在船头的那个人，在把握方向。有时候甚至需要打打鼓，鼓舞士气，并且一直思考前进的路在何方。这个阶段管理者是站在船头的掌舵人，往往能看到身边船只的情况，但有时候并不太能看到全局。掌舵人的核心职能，是让自己这条船，能一往直前。
+
+第三个阶段，管理者是站在船尾的人，他要看的可能不只是一个龙舟，而是好多龙舟，他可能自己划着一个小龙舟，在所有龙舟的后面。这过程中，他要去观察谁掉队了，以及究竟大家应该往什么地方去。这时指挥方向的方式，可能变成打电话给前面的龙舟，告诉怎么调整方向。管理者是站在最后面，看全局并兜底的一个孤独者。
+
+简单来说，第一个阶段是参与其中，第二个阶段是指引方向，第三个阶段是提供帮助。
+
+小结时刻
+
+玉伯对管理三个阶段的总结更多从自己的经验出发。第一个阶段，技术管理者最核心的要求是做表率，冲在一线。第二个阶段，管理者可能有种被拎起来的感觉，这个阶段管理者要学会授权，并调整自己的心态。第三个阶段，管理者一方面觉得被架空，一方面又很忙，这个阶段做好取舍，越感觉不可控的时候越要管理自己的时间，不被裹挟，才能看好全局，做好兜底。
+
+你是否同意玉伯所说？欢迎表达看法。我们下一讲见！
+
+                        
+                        
+                            

专栏/超级访谈：对话玉伯/结束语我想聊的一些与技术无关的话.md

@@ -0,0 +1,91 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            结束语 我想聊的一些与技术无关的话
+                            整个对话过程中，玉伯提到了一些他读过的书，比如《被讨厌的勇气》《卓有成效的管理者》《亚马逊逆向工作法》《大教堂与集市》《微习惯》《为什么是毛泽东》《邓小平传》《哈佛幸福公开课》《学会提问》等等，面临难题的时候，往往可以从书中寻找答案。
+
+最后一次采访的话题与技术、产品、管理无关，而是聊了聊他的个人兴趣，为什么对佛学和哲学感兴趣，以及对人生意义的思考，内心的追求、心中的自留地。
+
+以下为玉伯的自述：
+
+你好，我是玉伯。
+
+今天想跟你聊聊有关个人兴趣的私人话题。我为什么对佛学、哲学感兴趣，一个原因是学物理的人特别容易空虚，另一个原因是我现在做产品、做管理，总说要懂人性。当我在管理中遇到问题，去书中求解时，很多管理学书籍都会导向心理学和哲学。
+
+哲学学习之旅
+
+哲学的书籍我平常看得很杂，不太成体系，如果你想做基础了解，推荐你看《西方哲学史》。最近让我触动挺大的是康德的书《纯粹理性批判》，特别难懂，初看这个书名以为他要批判什么，读完发现原来我连书名都误解了，他所说的批判更多是对“纯粹理性”的考察和思辨。
+
+在接触哲学的过程中，我发现很好玩的是，发现哲学和科学、宗教有着千丝万缕的联系。哲学发展过程中有一条线是：
+
+
+从古希腊亚里士多德时代的朴素唯物主义，发展到理性唯物主义；再到以贝克莱等人为代表的唯心主义；然后再到以康德为代表的理性唯心主义，最后才是我们熟知的马克思、恩格斯的辩证唯物主义。
+
+
+朴素唯物主义就是我见即我得，看见的就是真实存在的。但很快会发现，我们看见的，只是物体的影像，并不是物体本身，只是大家在心里默默将物体和影像划等号了。理性唯物主义的一个认知，就是指出我们看到的是影像，同时认为影像等于实物。这两个阶段都比较好理解。
+
+再往下就到了理性唯心主义。有个很牛的哲学家，叫贝克莱。他提出，人看见的是影像，而影像不是实物，无法证明影像是实物，那么我看见的其实只是心里感受到的，也就是“我心即世界”。贝克莱甚至说，我看到的跟你看到的可能不一样，大家以为看到的东西一样，只是语言沟通的结果。贝克莱的言论，很快遭到科学界、哲学界一堆人的挑战：既然你说“我心即世界”，那为什么鱼不能在天上飞、鸟不能在水里游？如果“我心即世界”的话，应该说每个人看到的都不一样，理论上有些鱼会在天上飞，有些鸟会在水里游，为什么所有人哪怕通过语言沟通，最后都是说鸟在天上飞，鱼在水里游，这是怎么回事呢？所以“我心即世界”是不对的。当时哲学家们的讨论思辨很有意思，充满了思考的乐趣。
+
+真正把这个问题解决掉的是康德，康德有一个假说：实物跟影像其实跟认知有关系。康德开始研究人的认知，把人的认知分成：感性、理性、知性。
+
+感性一定程度上跟佛学里面的六根六入是一样的，眼﹑耳﹑鼻﹑舌﹑身﹑意，五官感受就是感知。如果把人比喻成一个电脑，感知就是输入。造物主就是这么造的，我们能够接触到的外界的输入只有这六个通道。这叫感性。
+
+理性是什么？理性就是人类特有的，比如说人类能总结出勾股定律，康德觉得只有人类才会从万物里总结出规律，且把规律用一个纯理性的方式提炼表达出来。我们观察狮子捕猎时，它们不知道勾三股四弦五，但是狮子知道捕猎时斜线是最短路径，动物有本能，有感知能力，但是动物没有理性，总结不出数学公式。是人类独有的理性，成就了数学、科学。数学并不是科学，数学就是一套游戏。数学的底层是一些基本假设，基于这些假设，纯理性推导出整个体系，一些科学定律也是纯理性。康德会很强调理性和感性是分开的，是有着巨大不同的。
+
+康德最大的创新，是提出人有知性。知性是什么呢？康德提出一个概念叫“先验统觉”。就是每个人的知性都来自个体的遗传。按照康德的说法，上帝就是这么创造你的，怎么来的你别问，每个人都有一套先验统觉的东西。这个先验统觉按我们现在的话，就如一个笔记本电脑，它的操作系统就是先验统觉。感性就是用感知给你输入，理性就是你这个 OS 还有一些产生智慧的能力，相当于算法或模型。
+
+康德的观点是，人不是一张白纸，因为有先验统觉，所以我看见的鱼跟你看见的鱼是一样的，这是操作系统决定的。然后你想再去问 WHY，请不要问，康德不会回答这个问题，他解决问题的方法是先划定范围，对我们可知的领域进行论证。这叫理性唯心主义，或者叫先验唯心主义。
+
+研究过哲学这一条线后，再来对照心理学。心理学我看过三个人的著作：弗洛伊德、阿德勒、荣格。弗洛伊德的经典著作是《梦的解析》，阿德勒最近些年比较火，《被讨厌的勇气》总结了阿德勒的思想，很符合当前这个时代。
+
+我最近在看荣格，他有本书叫《The Red Book》（《红书》），看着像圣经一样。我在研究康德的时候发现这里面有关联性，甚至从荣格心理学里面可以找到康德说的“先验统觉”是什么东西。荣格的核心理念是“人是群体的产物”。弗洛伊德说人是过去决定的，阿德勒说人是由未来决定的，荣格的观点是人不是由过去决定的，也不是由未来决定的，人是由人类这个物种决定的，或者说人是由群体环境决定的。
+
+在荣格的语境里有一个东西，叫做集体潜意识。我当时看的时候就觉得，这不就是先验统觉嘛。很多时候群体或者这个社会在往前发展，甚至说不同种族、不同国家产生冲突，我们以为不受影响，但实际上只要你生在中国你就是中国人。按集体潜意识说法，你的基因就是中国人的。
+
+在看这些书时，觉得挺有意思的，会发现不同学科之间，点可以串成线、连成面，这个过程很好玩。最近重读张小龙的《微信背后的产品观》，第一篇就讲到“人是环境的反应器”，我认为整本书最重要的就是这一句话。这句话其实就是来自先验统觉和集体潜意识的思想。
+
+研究哲学就是研究人本身，很多对人生的体验，都会被哲学串起来。
+
+我对人生意义的理解
+
+我是物理专业的，学物理的人一般特别容易空虚。为什么这么说呢？从科学的发展历史来看，会有一个很有趣的说法，休谟把科学的根基给挖了，康德则给科学封上了天花板。
+
+所谓休谟挖了科学的根基，是因为科学背后都是基本假设。比如说光速不可超越，比如说解析几何里的两点之间直线最短，这些都是公理，公理就是假设。这些基本假设怎么来的？无论是数学还是科学，最基本的方法只有归纳法和演绎法。但休谟说，哪怕发生了一万次都是对的，但是第一万零一次可能是错的，所以归纳法就是不靠谱的。而演绎的基础是归纳，所以只要把归纳法一否定，就等于把整个科学大厦的根基给动摇了。
+
+再说康德，康德除了提出“先验统觉”很厉害之外，他还提出一个不可知论，康德一方面在反对贝克莱，一方面也认可贝克莱。康德非常认可影像和实物是两件事，但这中间是无法证明的，这就是不可知论。因为不可知论的存在，意味着科学无论多么发达，以我们渺小人类的大脑是永远无法认知宇宙的真理或者宇宙全貌的。康德通过不可知论，给科学扣上了天花板。
+
+在研究这些理论的过程中，我发现无论是科学、数学还是社会学，最终都会基于一些假设出发，假设是一切的起点。不同民族或者不同文化之间的冲突，往往也是因为各自的基础假设不一样。数学领域有基本假设，物理学里也有基本假设。回到社会学领域，要回答人活着的意义，首先得研究人类社会的基本假设是什么呢？
+
+我深信一个词叫意义共同体，当我们问人生的意义在哪，就要先回答意义是什么，只要有一群人认为一件事有意义，它就有意义，意义就在于寻找共同体的过程中。
+
+比如说回到中华民族，要去研究中华民族底层假设是什么。我在看一些书，目前理解还非常粗浅。比如说费孝通的《乡土中国》，他对华夏民族的民族性是有研究的。他研究的是历史，但是现在我们在快速往前发展，可能民族的秉性、根性也在发生变化，我觉得这些根性的东西跟刚才说的基本假设有很大关系，这些根性里面，内植了一个群体的意义追求。我们活在当下，但意义往往是被历史中的群体的根性所决定的。
+
+我有跟大学里的一些老师交流，然后我发现我现在研究的这些东西，在学术派里是习以为常的，我以为发现了新大陆，原来只是人家不屑于讨论的话题。学术派现在在讨论啥呢？比如说北大哲学系有个教授他目前研究的话题，叫做《中国传统文化对现代社会的影响》。他们的研究我觉得有点偏科学，科学其实本身不追求真理，科学追求实用。社会学里，会进一步思考，到底应该去研究一个什么样的课题，反过来能对这个社会产生影响，或者是引起新的讨论或变革？
+
+曾和大学一位老师探讨，期待中国是不是有机会出现新的文艺复兴。如果会出现，那是会在江浙出现，还是在北京出现，会在什么地方呢？如果出现文艺复兴，该怎么去点火，怎么去推动其发生。我非常喜欢这样的话题讨论，我也挺期待有生之年，能见到新的文艺复兴出现。
+
+中国很多伟大思想家或者是哲学家都诞生在两种年代，一个是兵荒马乱的年代，比如春秋战国，还有一种年代是和平了一段时间，开始遇到困顿的时候。我觉得目前整个世界有点处于群体精神困顿的时代，在这个阶段是有可能出现文艺复兴的。
+
+我们看中国近代史，去看新中国成立的艰难，毛泽东、周恩来他们就是生活在一个兵荒马乱的时代。周恩来有句名言：“为中华之崛起而读书”。现在我们看到这句话，可能没什么体感，觉得很空很大，但在当年，为中华之崛起真的是周恩来、毛泽东他们天天想的事情。我们现在呢？
+
+文艺复兴是重新燃起整个社会的意义感，这个意义肯定也是多元化的，无论是老年人、中年人、年轻一代，不同的人群，会有不同的意义感。
+
+语雀的意义共同体
+
+最后围绕意义共同体我还想聊一个话题，是关于语雀的，我很少对外说。语雀长远畅想的，是构建多元化的意义共同体。语雀现在的数字花园概念，是指在线上，大家可以把自己所思所想沉淀成知识库，能够展现给别人看，这过程中有朋友认可，这是一种最简单的意义共同体。
+
+比如说公众号，也是建立最小意义共同体的通道。比如说像脉脉工作圈里的匿名吐槽，这也是一个小的意义共同体。
+
+回到语雀，当下聚焦做线上工具，尝试通过数字花园，让大家能够构建属于自己的意义共同体。更长远来看，可能 5-10 年以后，语雀真正想做的，可能是从线上能走向线下的意义共同体。现在互联网上的戾气很重，粉丝这个词感觉都是对用户的嘲讽。语雀真正想做的，是让人与人之间有更良好的互动，能彼此构建意义共同体。
+
+这可能真的会改变一个人的生活，改变人生轨迹。我喜欢创作，喜欢古典文学，一定程度上是因为在读大学的时候加入过两个社团，一个是古典文学社，还有一个是红楼梦社团。包括现在到蚂蚁，仍然有参加过一些社团，我内心感觉到社团对一个人的影响是很大的。哪怕这个社团只是你人生一个阶段，可能只是一段时间你参与过，但实际上在这个环境里交的一些朋友，你们之间一些探讨的话题，已经在改变你。
+
+中国社会如果有一些很好的线下意义共同体产品，能够让人与人的关系发生改变，那也许是一件非常有意义的事情。
+
+到这里，整个专栏就正式结束了，和你说声再见。感谢你坚持到现在，也欢迎你继续参与讨论，共同进步。
+
+                        
+                        
+                            

专栏/趣谈网络协议/00开篇词想成为技术牛人？先搞定网络协议！.md

@@ -0,0 +1,57 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            00 开篇词 想成为技术牛人？先搞定网络协议！
+                            你好，我是刘超，网易研究院云计算技术部的首席架构师。我主要负责两部分工作，对内支撑网易核心业务上云，对外帮助客户搞定容器化与微服务化架构。
+
+当极客时间约我做“趣谈网络协议”专栏的时候，我非常开心，因为网络协议也是我长期研究和关注的点。摸爬滚打15年，有了一些收获也溅了一身血，我才能在这里和你分享。
+
+为什么网络协议这么重要呢？为什么“计算机组成与系统结构”“数据结构与算法”“操作系统”“计算机网络”“编译原理”，会成为大学计算机的核心课程呢？至少看起来，这些内容没有“多少天搞定MFC、Structs”这样的内容更容易帮你找到工作。我毕业的时候，也感到很困惑。
+
+不过当时我抱着一个理想，也可能是大多数程序员的理想：我要做技术牛人，我要搞定大系统。
+
+工作15年，我在EMC做过类似GFS的分布式存储开发，做过基于Lucene的搜索引擎，做过Hadoop的运维；在HP和华为做过OpenStack的开发、实施和解决方案；还创业倒腾过Mesos容器平台，后来在网易做Kubernetes。
+
+随着见过的世面越来越多，我渐渐发现，无论是对于大规模系统的架构，还是对于程序员的个人职业生涯，网络和网络协议都是绕不过去的坎儿。
+
+集群规模一大，我们首先想到的就是网络互通的问题；应用吞吐量压不上去，我们首先想到的也是网络互通的问题。不客气地讲，很多情况下，只要搞定了网络，一个大型系统也就搞定了一半。所以，要成为技术牛人，搞定大系统，一定要过网络这一关，而网络协议在网络中占有举足轻重的地位。
+
+相信大部分人都思考过“技术变化太快，容易过时”的问题。毕竟，技术浪潮一浪接一浪，新技术层出不穷。从搜索引擎、大数据、云计算，到人工智能、区块链，简直就是“你方唱罢我登场”。这里面究竟有没有最本质的东西，使得你掌握了它，就能在新技术的滚滚浪潮中，保持快速学习的能力？
+
+通过对大量开源技术的代码进行分析，我发现很多技术看起来轰轰烈烈，扒下外衣，本质的东西其实就是基础知识和核心概念。想要不被滚滚而来的新技术淘汰，就要掌握这些可以长久使用的知识，而网络协议就是值得你学习，而且是到40岁之后依然有价值的知识。
+
+但是，要想真正学习和掌握网络协议，也并非易事。下面这些场景，你是不是也感同身受呢？
+
+
+网络协议知识点太多，学完记不住。我们都学过计算机网络课程，学的时候感觉并不难。尤其这门课没有公式，更像是文科。学了一大堆，也背了一大堆，应付完考试之后，最终都“还给老师”了。
+
+看上去懂了，但是经不住问。没关系，网上有很多的文章嘛。于是，你会搜索很多文章去看。看的时候，你感觉别人说的很有道理，好像理解了，但是经不住问，一问就发现，你只是了解了大概的流程，很多细节还是不知道。所以说，从能看懂到能给别人讲明白，中间还有很长一段距离。
+
+知识学会了，实际应用依旧不会。细节都摸索得差不多了，但是当你自己去应用和调试的时候，发现还是没有思路。比如，当创建出来的虚拟机不能上网的时候，该怎么办呢？学过的东西，怎么还是不会用？
+
+
+我把这样的网络协议学习过程总结为：一看觉得懂，一问就打鼓，一用就糊涂。
+
+那网络协议究竟该怎么学？基于这个问题，我决定从以下三个角度和你分享我所理解的网络协议。
+
+第一，我会从身边经常见到的事情出发，用故事来讲解各种网络协议，然后慢慢扩展到不熟悉的领域。
+
+例如，每个人都会查看IP地址，那我们就从这个命令开始，展开一些概念；很多人都在大学宿舍组过简单的网络来打游戏，我就从宿舍里最简单的网络概念开始讲；然后说到办公室，说到日常上网、购物、视频下载等过程涉及的协议；最后说到最陌生的数据中心。
+
+第二，我会用贴近场景的方式来讲解网络协议，将各个层次的关系串起来，而非孤立地讲解某个概念。
+
+常见的计算机网络课程往往会按照网络分层，一层一层地讲，却很少讲层与层之间的关系。例如，我们学习路由协议的时候，在真实场景中，这么多的算法和二层是什么关系呢？和四层又是什么关系呢？例如，在真实的网络通信中，我们访问一个网站，做一个支付，在TCP进行三次握手的时候，IP层在干嘛？MAC层又在干嘛？这些你是不是都清楚？
+
+第三，我会在讲解完各个层次的网络协议之后，着重剖析如何在当下热门领域使用这些协议，比如云计算、容器和微服务。
+
+一方面你可以知道网络协议真实应用的地方，另一方面你也可以通过上手使用云计算、容器、微服务来进一步加深对于协议的理解。
+
+千里之行，始于足下。不管何时，我相信，扎实的功底和过硬的技术，都会是你职业发展的助力器。
+
+希望这个专栏，不仅可以帮你理清繁杂的网络协议概念，帮你构建一个精准的网络协议知识框架，帮你在热门领域应用这些底层知识，更重要的是给你一种学习知识的方法和态度：看似最枯燥、最基础的东西往往具有最长久的生命力。
+
+                        
+                        
+                            

专栏/趣谈网络协议/01为什么要学习网络协议？.md

@@ -0,0 +1,156 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            01 为什么要学习网络协议？
+                            《圣经》中有一个通天塔的故事，大致是说，上帝为了阻止人类联合起来，就让人类说不同的语言。人类没法儿沟通，达不成“协议”，通天塔的计划就失败了。
+
+但是千年以后，有一种叫“程序猿”的物种，敲着一种这个群体通用的语言，连接着全世界所有的人，打造这互联网世界的通天塔。如今的世界，正是因为互联网，才连接在一起。
+
+当”Hello World!“从显示器打印出来的时候，还记得你激动的心情吗？
+
+public class HelloWorld {
+  public static void main(String[] args){
+    System.out.println("Hello World!");
+  }
+}
+
+
+如果你是程序员，一定看得懂上面这一段文字。这是每一个程序员向计算机世界说“你好，世界”的方式。但是，你不一定知道，这段文字也是一种协议，是人类和计算机沟通的协议，只有通过这种协议，计算机才知道我们想让它做什么。
+
+协议三要素
+
+当然，这种协议还是更接近人类语言，机器不能直接读懂，需要进行翻译，翻译的工作教给编译器，也就是程序员常说的compile。这个过程比较复杂，其中的编译原理非常复杂，我在这里不进行详述。
+
+
+
+但是可以看得出，计算机语言作为程序员控制一台计算机工作的协议，具备了协议的三要素。
+
+
+语法，就是这一段内容要符合一定的规则和格式。例如，括号要成对，结束要使用分号等。
+
+语义，就是这一段内容要代表某种意义。例如数字减去数字是有意义的，数字减去文本一般来说就没有意义。
+
+顺序，就是先干啥，后干啥。例如，可以先加上某个数值，然后再减去某个数值。
+
+
+会了计算机语言，你就能够教给一台计算机完成你的工作了。恭喜你，入门了！
+
+但是，要想打造互联网世界的通天塔，只教给一台机器做什么是不够的，你需要学会教给一大片机器做什么。这就需要网络协议。只有通过网络协议，才能使一大片机器互相协作、共同完成一件事。
+
+这个时候，你可能会问，网络协议长啥样，这么神奇，能干成啥事？我先拿一个简单的例子，让你尝尝鲜，然后再讲一个大事。
+
+当你想要买一个商品，常规的做法就是打开浏览器，输入购物网站的地址。浏览器就会给你显示一个缤纷多彩的页面。
+
+那你有没有深入思考过，浏览器是如何做到这件事情的？它之所以能够显示缤纷多彩的页面，是因为它收到了一段来自HTTP协议的“东西”。我拿网易考拉来举例，格式就像下面这样：
+
+HTTP/1.1 200 OK
+Date: Tue, 27 Mar 2018 16:50:26 GMT
+Content-Type: text/html;charset=UTF-8
+Content-Language: zh-CN
+
+<!DOCTYPE html>
+<html>
+<head>
+<base href="https://pages.kaola.com/" />
+<meta charset="utf-8"/> <title>网易考拉3周年主会场</title>
+
+
+这符合协议的三要素吗？我带你来看一下。
+
+首先，符合语法，也就是说，只有按照上面那个格式来，浏览器才认。例如，上来是状态，然后是首部，然后是内容。
+
+第二，符合语义，就是要按照约定的意思来。例如，状态200，表述的意思是网页成功返回。如果不成功，就是我们常见的“404”。
+
+第三，符合顺序，你一点浏览器，就是发送出一个HTTP请求，然后才有上面那一串HTTP返回的东西。
+
+浏览器显然按照协议商定好的做了，最后一个五彩缤纷的页面就出现在你面前了。
+
+我们常用的网络协议有哪些？
+
+接下来揭秘我要说的大事情，“双十一”。这和我们要讲的网络协议有什么关系呢？
+
+在经济学领域，有个伦纳德·里德（Leonard E. Read）创作的《铅笔的故事》。这个故事通过一个铅笔的诞生过程，来讲述复杂的经济学理论。这里，我也用一个下单的过程，看看互联网世界的运行过程中，都使用了哪些网络协议。
+
+你先在浏览器里面输入 https://www.kaola.com ，这是一个URL。浏览器只知道名字是“www.kaola.com”，但是不知道具体的地点，所以不知道应该如何访问。于是，它打开地址簿去查找。可以使用一般的地址簿协议DNS去查找，还可以使用另一种更加精准的地址簿查找协议HTTPDNS。
+
+无论用哪一种方法查找，最终都会得到这个地址：106.114.138.24。这个是IP地址，是互联网世界的“门牌号”。
+
+知道了目标地址，浏览器就开始打包它的请求。对于普通的浏览请求，往往会使用HTTP协议；但是对于购物的请求，往往需要进行加密传输，因而会使用HTTPS协议。无论是什么协议，里面都会写明“你要买什么和买多少”。
+
+
+
+DNS、HTTP、HTTPS所在的层我们称为应用层。经过应用层封装后，浏览器会将应用层的包交给下一层去完成，通过socket编程来实现。下一层是传输层。传输层有两种协议，一种是无连接的协议UDP，一种是面向连接的协议TCP。对于支付来讲，往往使用TCP协议。所谓的面向连接就是，TCP会保证这个包能够到达目的地。如果不能到达，就会重新发送，直至到达。
+
+TCP协议里面会有两个端口，一个是浏览器监听的端口，一个是电商的服务器监听的端口。操作系统往往通过端口来判断，它得到的包应该给哪个进程。
+
+
+
+传输层封装完毕后，浏览器会将包交给操作系统的网络层。网络层的协议是IP协议。在IP协议里面会有源IP地址，即浏览器所在机器的IP地址和目标IP地址，也即电商网站所在服务器的IP地址。
+
+
+
+操作系统既然知道了目标IP地址，就开始想如何根据这个门牌号找到目标机器。操作系统往往会判断，这个目标IP地址是本地人，还是外地人。如果是本地人，从门牌号就能看出来，但是显然电商网站不在本地，而在遥远的地方。
+
+操作系统知道要离开本地去远方。虽然不知道远方在何处，但是可以这样类比一下：如果去国外要去海关，去外地就要去网关。而操作系统启动的时候，就会被DHCP协议配置IP地址，以及默认的网关的IP地址192.168.1.1。
+
+操作系统如何将IP地址发给网关呢？在本地通信基本靠吼，于是操作系统大吼一声，谁是192.168.1.1啊？网关会回答它，我就是，我的本地地址在村东头。这个本地地址就是MAC地址，而大吼的那一声是ARP协议。
+
+
+
+于是操作系统将IP包交给了下一层，也就是MAC层。网卡再将包发出去。由于这个包里面是有MAC地址的，因而它能够到达网关。
+
+网关收到包之后，会根据自己的知识，判断下一步应该怎么走。网关往往是一个路由器，到某个IP地址应该怎么走，这个叫作路由表。
+
+路由器有点像玄奘西行路过的一个个国家的一个个城关。每个城关都连着两个国家，每个国家相当于一个局域网，在每个国家内部，都可以使用本地的地址MAC进行通信。
+
+一旦跨越城关，就需要拿出IP头来，里面写着贫僧来自东土大唐（就是源IP地址），欲往西天拜佛求经（指的是目标IP地址）。路过宝地，借宿一晚，明日启程，请问接下来该怎么走啊？
+
+
+
+城关往往是知道这些“知识”的，因为城关和临近的城关也会经常沟通。到哪里应该怎么走，这种沟通的协议称为路由协议，常用的有OSPF和BGP。
+
+
+
+城关与城关之间是一个国家，当网络包知道了下一步去哪个城关，还是要使用国家内部的MAC地址，通过下一个城关的MAC地址，找到下一个城关，然后再问下一步的路怎么走，一直到走出最后一个城关。
+
+最后一个城关知道这个网络包要去的地方。于是，对着这个国家吼一声，谁是目标IP啊？目标服务器就会回复一个MAC地址。网络包过关后，通过这个MAC地址就能找到目标服务器。
+
+目标服务器发现MAC地址对上了，取下MAC头来，发送给操作系统的网络层。发现IP也对上了，就取下IP头。IP头里会写上一层封装的是TCP协议，然后将其交给传输层，即TCP层。
+
+在这一层里，对于收到的每个包，都会有一个回复的包说明收到了。这个回复的包绝非这次下单请求的结果，例如购物是否成功，扣了多少钱等，而仅仅是TCP层的一个说明，即收到之后的回复。当然这个回复，会沿着刚才来的方向走回去，报个平安。
+
+因为一旦出了国门，西行路上千难万险，如果在这个过程中，网络包走丢了，例如进了大沙漠，或者被强盗抢劫杀害怎么办呢？因而到了要报个平安。
+
+如果过一段时间还是没到，发送端的TCP层会重新发送这个包，还是上面的过程，直到有一天收到平安到达的回复。这个重试绝非你的浏览器重新将下单这个动作重新请求一次。对于浏览器来讲，就发送了一次下单请求，TCP层不断自己闷头重试。除非TCP这一层出了问题，例如连接断了，才轮到浏览器的应用层重新发送下单请求。
+
+当网络包平安到达TCP层之后，TCP头中有目标端口号，通过这个端口号，可以找到电商网站的进程正在监听这个端口号，假设一个Tomcat，将这个包发给电商网站。
+
+
+
+电商网站的进程得到HTTP请求的内容，知道了要买东西，买多少。往往一个电商网站最初接待请求的这个Tomcat只是个接待员，负责统筹处理这个请求，而不是所有的事情都自己做。例如，这个接待员要告诉专门管理订单的进程，登记要买某个商品，买多少，要告诉管理库存的进程，库存要减少多少，要告诉支付的进程，应该付多少钱，等等。
+
+如何告诉相关的进程呢？往往通过RPC调用，即远程过程调用的方式来实现。远程过程调用就是当告诉管理订单进程的时候，接待员不用关心中间的网络互连问题，会由RPC框架统一处理。RPC框架有很多种，有基于HTTP协议放在HTTP的报文里面的，有直接封装在TCP报文里面的。
+
+当接待员发现相应的部门都处理完毕，就回复一个HTTPS的包，告知下单成功。这个HTTPS的包，会像来的时候一样，经过千难万险到达你的个人电脑，最终进入浏览器，显示支付成功。
+
+小结
+
+看到了吧，一个简简单单的下单过程，中间牵扯到这么多的协议。而管理一大片机器，更是一件特别有技术含量的事情。除此之外，像最近比较火的云计算、容器、微服务等技术，也都需要借助各种协议，来达成大规模机器之间的合作。
+
+我在这里列一下之后要讲的网络协议，之后我会按照从底层到上层的顺序来讲述。
+
+
+
+上面的“双十一”故事只是为了给你一个大致的框架，这里面有些协议，我在故事里已经提到了，有些还没有提到。在这门课的最后一章，当所有的协议都讲过之后，我会再重新讲一遍这个故事，到时候你就能明白更多的细节。
+
+最后，学完了这一节，给你留一个问题吧。
+
+当网络包到达一个城关的时候，可以通过路由表得到下一个城关的IP地址，直接通过IP地址找就可以了，为什么还要通过本地的MAC地址呢？
+
+欢迎你留言和我讨论。趣谈网络协议，我们下期见！
+
+                        
+                        
+                            

专栏/趣谈网络协议/02网络分层的真实含义是什么？.md

@@ -0,0 +1,111 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            02 网络分层的真实含义是什么？
+                            长时间从事计算机网络相关的工作，我发现，计算机网络有一个显著的特点，就是这是一个不仅需要背诵，而且特别需要将原理烂熟于胸的学科。很多问题看起来懂了，但是就怕往细里问，一问就发现你懂得没有那么透彻。
+
+我们上一节列了之后要讲的网络协议。这些协议本来没什么稀奇，每一本教科书都会讲，并且都要求你背下来。因为考试会考，面试会问。可以这么说，毕业了去找工作还答不出这类题目的，那你的笔试基本上也就挂了。
+
+当你听到什么二层设备、三层设备、四层LB和七层LB中层的时候，是否有点一头雾水，不知道这些所谓的层，对应的各种协议具体要做什么“工作”？
+
+这四个问题你真的懂了吗？
+
+因为教科书或者老师往往会打一个十分不恰当的比喻：为什么网络要分层呀？因为不同的层次之间有不同的沟通方式，这个叫作协议。例如，一家公司也是分“层次”的，分总经理、经理、组长、员工。总经理之间有他们的沟通方式，经理和经理之间也有沟通方式，同理组长和员工。有没有听过类似的比喻？
+
+那么第一个问题来了。请问经理在握手的时候，员工在干什么？很多人听过TCP建立连接的三次握手协议，也会把它当知识点背诵。同理问你，TCP在进行三次握手的时候，IP层和MAC层对应都有什么操作呢？
+
+除了上面这个不恰当的比喻，教科书还会列出每个层次所包含的协议，然后开始逐层地去讲这些协议。但是这些协议之间的关系呢？却很少有教科书会讲。
+
+学习第三层的时候会提到，IP协议里面包含目标地址和源地址。第三层里往往还会学习路由协议。路由就像中转站，我们从原始地址A到目标地址D，中间经过两个中转站A->B->C->D，是通过路由转发的。
+
+那么第二个问题来了。A知道自己的下一个中转站是B，那从A发出来的包，应该把B的IP地址放在哪里呢？B知道自己的下一个中转站是C，从B发出来的包，应该把C的IP地址放在哪里呢？如果放在IP协议中的目标地址，那包到了中转站，怎么知道最终的目的地址是D呢？
+
+教科书不会通过场景化的例子，将网络包的生命周期讲出来，所以你就会很困惑，不知道这些协议实际的应用场景是什么。
+
+我再问你一个问题。你一定经常听说二层设备、三层设备。二层设备处理的通常是MAC层的东西。那我发送一个HTTP的包，是在第七层工作的，那是不是不需要经过二层设备？或者即便经过了，二层设备也不处理呢？或者换一种问法，二层设备处理的包里，有没有HTTP层的内容呢？
+
+最终，我想问你一个综合的问题。从你的电脑，通过SSH登录到公有云主机里面，都需要经历哪些过程？或者说你打开一个电商网站，都需要经历哪些过程？说得越详细越好。
+
+实际情况可能是，很多人回答不上来。尽管对每一层都很熟悉，但是知识点却串不起来。
+
+上面的这些问题，有的在这一节就会有一个解释，有的则会贯穿我们整个课程。好在后面一节中我会举一个贯穿的例子，将很多层的细节讲过后，你很容易就能把这些知识点串起来。
+
+网络为什么要分层？
+
+这里我们先探讨第一个问题，网络为什么要分层？因为，是个复杂的程序都要分层。
+
+理解计算机网络中的概念，一个很好的角度是，想象网络包就是一段Buffer，或者一块内存，是有格式的。同时，想象自己是一个处理网络包的程序，而且这个程序可以跑在电脑上，可以跑在服务器上，可以跑在交换机上，也可以跑在路由器上。你想象自己有很多的网口，从某个口拿进一个网络包来，用自己的程序处理一下，再从另一个网口发送出去。
+
+当然网络包的格式很复杂，这个程序也很复杂。复杂的程序都要分层，这是程序设计的要求。比如，复杂的电商还会分数据库层、缓存层、Compose层、Controller层和接入层，每一层专注做本层的事情。
+
+程序是如何工作的？
+
+我们可以简单地想象“你”这个程序的工作过程。
+
+
+
+当一个网络包从一个网口经过的时候，你看到了，首先先看看要不要请进来，处理一把。有的网口配置了混杂模式，凡是经过的，全部拿进来。
+
+拿进来以后，就要交给一段程序来处理。于是，你调用process_layer2(buffer)。当然，这是一个假的函数。但是你明白其中的意思，知道肯定是有这么个函数的。那这个函数是干什么的呢？从Buffer中，摘掉二层的头，看一看，应该根据头里面的内容做什么操作。
+
+假设你发现这个包的MAC地址和你的相符，那说明就是发给你的，于是需要调用process_layer3(buffer)。这个时候，Buffer里面往往就没有二层的头了，因为已经在上一个函数的处理过程中拿掉了，或者将开始的偏移量移动了一下。在这个函数里面，摘掉三层的头，看看到底是发送给自己的，还是希望自己转发出去的。
+
+如何判断呢？如果IP地址不是自己的，那就应该转发出去；如果IP地址是自己的，那就是发给自己的。根据IP头里面的标示，拿掉三层的头，进行下一层的处理，到底是调用process_tcp(buffer)呢，还是调用process_udp(buffer)呢？
+
+假设这个地址是TCP的，则会调用process_tcp(buffer)。这时候，Buffer里面没有三层的头，就需要查看四层的头，看这是一个发起，还是一个应答，又或者是一个正常的数据包，然后分别由不同的逻辑进行处理。如果是发起或者应答，接下来可能要发送一个回复包；如果是一个正常的数据包，就需要交给上层了。交给谁呢？是不是有process_http(buffer)函数呢？
+
+没有的，如果你是一个网络包处理程序，你不需要有process_http(buffer)，而是应该交给应用去处理。交给哪个应用呢？在四层的头里面有端口号，不同的应用监听不同的端口号。如果发现浏览器应用在监听这个端口，那你发给浏览器就行了。至于浏览器怎么处理，和你没有关系。
+
+浏览器自然是解析HTML，显示出页面来。电脑的主人看到页面很开心，就点了鼠标。点击鼠标的动作被浏览器捕获。浏览器知道，又要发起另一个HTTP请求了，于是使用端口号，将请求发给了你。
+
+你应该调用send_tcp(buffer)。不用说，Buffer里面就是HTTP请求的内容。这个函数里面加一个TCP的头，记录下源端口号。浏览器会给你目的端口号，一般为80端口。
+
+然后调用send_layer3(buffer)。Buffer里面已经有了HTTP的头和内容，以及TCP的头。在这个函数里面加一个IP的头，记录下源IP的地址和目标IP的地址。
+
+然后调用send_layer2(buffer)。Buffer里面已经有了HTTP的头和内容、TCP的头，以及IP的头。这个函数里面要加一下MAC的头，记录下源MAC地址，得到的就是本机器的MAC地址和目标的MAC地址。不过，这个还要看当前知道不知道，知道就直接加上；不知道的话，就要通过一定的协议处理过程，找到MAC地址。反正要填一个，不能空着。
+
+万事俱备，只要Buffer里面的内容完整，就可以从网口发出去了，你作为一个程序的任务就算告一段落了。
+
+揭秘层与层之间的关系
+
+知道了这个过程之后，我们再来看一下原来困惑的问题。
+
+首先是分层的比喻。所有不能表示出层层封装含义的比喻，都是不恰当的。总经理握手，不需要员工在吧，总经理之间谈什么，不需要员工参与吧，但是网络世界不是这样的。正确的应该是，总经理之间沟通的时候，经理将总经理放在自己兜里，然后组长把经理放自己兜里，员工把组长放自己兜里，像套娃娃一样。那员工直接沟通，不带上总经理，就不恰当了。
+
+现实生活中，往往是员工说一句，组长补充两句，然后经理补充两句，最后总经理再补充两句。但是在网络世界，应该是总经理说话，经理补充两句，组长补充两句，员工再补充两句。
+
+那TCP在三次握手的时候，IP层和MAC层在做什么呢？当然是TCP发送每一个消息，都会带着IP层和MAC层了。因为，TCP每发送一个消息，IP层和MAC层的所有机制都要运行一遍。而你只看到TCP三次握手了，其实，IP层和MAC层为此也忙活好久了。
+
+这里要记住一点：只要是在网络上跑的包，都是完整的。可以有下层没上层，绝对不可能有上层没下层。
+
+所以，对TCP协议来说，三次握手也好，重试也好，只要想发出去包，就要有IP层和MAC层，不然是发不出去的。
+
+经常有人会问这样一个问题，我都知道那台机器的IP地址了，直接发给他消息呗，要MAC地址干啥？这里的关键就是，没有MAC地址消息是发不出去的。
+
+所以如果一个HTTP协议的包跑在网络上，它一定是完整的。无论这个包经过哪些设备，它都是完整的。
+
+所谓的二层设备、三层设备，都是这些设备上跑的程序不同而已。一个HTTP协议的包经过一个二层设备，二层设备收进去的是整个网络包。这里面HTTP、TCP、 IP、 MAC都有。什么叫二层设备呀，就是只把MAC头摘下来，看看到底是丢弃、转发，还是自己留着。那什么叫三层设备呢？就是把MAC头摘下来之后，再把IP头摘下来，看看到底是丢弃、转发，还是自己留着。
+
+小结
+
+总结一下今天的内容，理解网络协议的工作模式，有两个小窍门：
+
+
+始终想象自己是一个处理网络包的程序：如何拿到网络包，如何根据规则进行处理，如何发出去；
+始终牢记一个原则：只要是在网络上跑的包，都是完整的。可以有下层没上层，绝对不可能有上层没下层。
+
+
+最后，给你留两个思考题吧。
+
+
+如果你也觉得总经理和员工的比喻不恰当，你有更恰当的比喻吗？
+要想学习网络协议，IP这个概念是最最基本的，那你知道如何查看IP地址吗？
+
+
+欢迎你留言和我讨论。趣谈网络协议，我们下期见！
+
+                        
+                        
+