Conway's law：系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。
因为私人的原因，我前段时间换了工作，虽然仍然是在网络领域，仍然是做研发。但有三点很大的不同：1.从乙方到了甲方。2. 从一个扁平的创业公司进入了一个等级森严的大型企业。3. 从研发驱动的工作环境进入了业务和运营驱动的工作环境。这次转变带给了我一些全新的视角，很有趣。之前一些困惑也变得慢慢有了自己的答案：Conway's law，这个一度被我严重忽视的概念竟然是解答很多问题的根源所在。
困惑一：甲方需要什么样的SDN产品
甲方需要的是最符合其组织架构的SDN产品而不是最好的SDN产品。如果几个厂家的SDN产品在功能上都基本满足需求，在价格上差别也不大，那么这个产品的使用和运维方式是否能够对应到企业现有的组织结构上去就成为了最关键的因素。也就是要尽可能的让甲方已有的研发，测试，运维人员从事和之前差不多的工作。这里的差不多是指：新系统的引入，不能让既成事实的团队职责发生太大的变化。这里拿几个常见的SDN功能举例子。
快速部署(zero touch provisioning)：一般来说，这是一个好feature。最大的好处不仅仅是缩短了部署交付的时间，而是让负责部署交付的部门能够有kpi邀功：去年上线新集群用了一个月；今年在任务更重，人力不变的前提下只用了一周，效率提升了，皆大欢喜。
零接触运维(zero touch operation)：控制器接管了所有的交换机，所有的运维操作全部在控制器完成。这个功能非常酷，似乎也符合自动化运维的愿景。但对于那些运维主导的企业而言有个致命的问题：它让运维人员的职责大幅度减少。面对这样的客户，系统设计的原则之一就是要让人成为系统使用环节当中必不可少的一部分，系统的亮点不应该是替代人的职责，而是辅助人的工作。更合理的做法举例：提供puppet，chef或者rest接口，能够让运维人员轻松的编写脚本控制设备。
漂亮的前端：这是demo时最重要的feature，没有之一。但对于绝大多数甲方，尤其是那些研发话语权比较大的甲方而言，重写UI是必然发生的。一方面新系统需要和甲方已有的系统统一前端，更重要的是甲方研发也有kpi的压力，自研前端是难度最低，曝光度最高的项目。面对这样的客户，漂亮的前端反而不如详细的rest api文档和灵活的可定制的前端模块有意义。
快速故障定位：这个同样需要因甲方而异。对于运维主导的甲方，这个功能做得越完整越好。而对于研发具有相当话语权的甲方而言，却完全不是这样。研发所面对的故障定位不单单是一次采购的设备，而是企业现网的所有设备。他们需要一套比较通用的故障定位方法：snmp，各种计数器，下发ACL定位包的路径等等。如果能够把这些基础服务包装好开放给具有相当研发能力的客户，其价值要远远高于自己做一个完整的故障定位feature。
这些例子还可以举出很多。核心思想只有一条：目前这个阶段，SDN的自动化程度还真的不是越高越好，而是越符合甲方的组织结构越好。
困惑二：为什么微服务在技术上如此不堪，却能够大行其道
我一直以来对微服务颇有微词，因为在我看来微服务是糟糕系统设计的代名词：数据库充斥着冗余数据，一致性糟糕；代码里充斥着冗余逻辑，根本没有复用；系统间本来能够推送信息的，却采用轮询...
不少人认为解耦单体服务能够更快的迭代编译上线，这是微服务大行其道的根本原因。但我却觉着这个原因太单薄，也许是必要但绝对不是充分条件。与此同时，面对微服务势如破竹的攻占了一个又一个的系统高地，我知道自己一定是忽略了某些东西。现在我知道这个东西又是Conway's law。
出了事故，避免部门之间推卸责任最好的方法就是事先把责任界定清楚。微服务天生能够把责任界定清楚。仅此一条，微服务想不流行都难。知乎上有一篇话糙理不糙的论述，把微服务的一些原则总结的非常到位。对于这篇文章中“让他们来取”和”组织墙“这两个概念，我还有很多话想说，会专门开一篇。
这段时间整个人的思维方式发生了比较大的变化，打心眼里希望摆脱之前偏执的工程师审美，试图从更多元的角度来审视自己一直以来形成的思维定式。相信这是一个好的转变。
