请玉伯一起来聊一聊“所向无敌的土方法”
7n5e 9年前
玉伯对我的《开发团队的效率》（http://coolshell.cn/articles/11656.html）一文做了评论，觉得理想化，觉得不接地气，我截图如下。
首先，让我来尝试理解玉伯一下，然后，我会给出当时最实际的案例，我非常好奇玉伯那“所向无敌的土方法”
一、是“常识”还是“理想”
1）我在文中：“一个全格的程序员应该能够掌握多个语言，也能够负责多个模块甚至不同的职责”，玉伯认为这就算“全栈了”？这就算“牛人了”？玉伯，你是这么理解的么？
2）我认为，正常的工程师需要了解需求，需要做自测，需要了解运维。玉伯认为这就是“全栈”了？，这就是“牛人”了？这就是一种“理想”，一种“不接地气”么？玉伯是这么理解的么？
3）我在Watchdog一节中说的，解决问题就要解决在根上，不要绕。玉伯认为这么正常的思维方式就是“不接地气”么，就是“理想”么？
4）我在接力棒开发中，说到了，团队能够很好合作的前提是需要有一个比较统一的开发框架或是开发协议，需要把自己当成服务者，而不是对方式的保姆，玉伯认为这么做就是太理想了么？
玉伯，你不觉得我说的这些都不是理想，而就是一种常识么？
二、求“所向无敌的土方法”
我还是给你几个案例吧，我很想知道你那些“所向无敌的土方法”。
声明一下，我本来不想给这些案例的，
但是我想和玉伯辩论一下，是“理想”还是“常识”，
同时，我非常非常想知道——玉伯的“所向无敌土方法”说的究竟是什么？
1） 我的文章里提到了这么一篇文章：《阿里云OCS超时问题的分析与解决》http://blog.aliyun.com/341，玉伯同学看看，当然，我不 确定你能不能看得懂。这篇文章的的内涵是：“阿里云连一个小小的keepalive参数都没有被整体设计过，导致问题，排查起来相当困难”，就是说，这篇 文章暴露了阿里云有多Low。想问一下玉伯的土方法是什么（比较讽刺的，这篇文章的最后一段是“这是我们工作中最大的乐趣！”）（在这个案例下，请玉伯说一下你的所向无敌的土方法）
2）我刚到阿里云做VNC的时候，看到做这个事有三个人分别来自三个团队，一个是搞底层的，一个是搞Tengine， 一个是搞控制系统的。他们三个人都不了解别人的系统，然后，每个人都站在自己角度给我一个完全不一样的方案。时间估计要做3个月，因为要各种配合，开个 会，开发，测试，运维，网络……来一堆人，近20个人，各种扯，我很崩溃。我很难理解这么一个小玩意需要这么多人。于是我和另一个同学，两个人，不到三周 就把控制系统、Tengine、控制系统搞完了，还开发了产品不要的OpenAPI，我连前端都做了，要不是前端在重构，代码进不去。（在这个案例下，请玉伯说一下你的所向无敌的土方法）
3） 阿里云虚拟机有一些因为控制系统里的状态和实际状态不一致。控制系统认为这是一块新硬盘，但实际是用户在用的，于是用户一个重起就导致我们的控制系统把这 块硬盘给格式化了，造成了用户数据丢失。玉伯，如果你找找内网，你还可以看到相关的贴子。就是高层们在大谈各种“意识形态”的东西——什么客户第一啊，什 么要和用户坐在一架飞机上，等等。我们在讨论这个问题的时候，主管说，要开发一个巡检系统，实时监控控制系统和实际情况有什么不一样的。我说，我不同意， 因为，a)知道了不一样谁是对的呢？b)这并没有解决问题啊。既然状态不一致了，要就找到根本原因为什么不一致，然后彻底解决。（在这个案例下，请玉伯说一下你的所向无敌的土方法）
4） 阿里云存储有一次需要开一个新的集群，一个运维的同学在部署这个新集群的时候，把一个现有的生产线上的集群的配置copy到新集群那边修改。但是配置项太 多，改漏了一些，导致这个新的集群连接到了正在生产的集群，导致一个重大故障。我们在周例会上review这个案例，主管说，让每个云产品团队都开发一个 自己的权限管理系统，不要让什么东西都能被修改。我说我不建议这么做，因为，a) 权限系统并不解决这个问题，另外，带来更多的维护工作，b）要开发也不要每个团队各做各的啊，应该是统一做啊，c)最重要的是，这事应该是自动化部署的问 题啊。主管说，反正你早晚要这个权限系统的，另外，以后上线，要两个同学，一个是在操作，另一个在旁边验证操作。我心里直嘀咕：“这事就是人肉运维出的 事，加更多的人让其更人肉”？我的确很难理解。（在这个案例下，请玉伯说一下你的所向无敌的土方法）