@Lenciel

修复无法获取IP的MBP

周末在家，掏出电脑要干活，发现机器关机了。

用 mbp 的人都知道，这机器基本上不用关，合上就走，打开就用。

用 mbp 的人也知道，这机器有时候你打开发现它关过，再开就行。

结果这次不太一样，连上 wifi 之后，分配了一个169.254.175.53的所谓self-assigned的 IP。这个 IP 应该是苹果设计来在没有网络连接的情况下 ad-hoc 的。

立马把有线连上试了一下，排除是 wifi 的问题。结果一样：

Don't touch me

当时其他设备都跑得很欢畅，路由器也设置了正确的 DHCP 方式，所以是本机的问题无疑了。Google 了一下，发现官网有一个十页的帖子，充满了血泪，但是没有解决方案。

然后发现还有很多别的帖子里有各种招数，比如更新 DHCP Lease 的，把网卡删了加上的，把上网的 profile 删了重加的，清空 NVRAM/SMC 的，重装系统的…

Hmmmm，重装系统…懒如狗的先 tcpdump 了一下网卡，问问它究竟是怎么想的：

$ sudo tcpdump -i en0

11:10:18.118413 IP 172.16.95.124.bootps > 10.250.115.106.bootpc: BOOTP/DHCP, Reply, length 333
11:10:26.417237 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 8c:85:90:d1:82:a7 (oui Unknown), length 300
11:10:26.440460 IP 172.16.95.123.bootps > 10.250.113.2.bootpc: BOOTP/DHCP, Reply, length 333
11:10:26.440470 IP 172.16.95.124.bootps > 10.250.115.106.bootpc: BOOTP/DHCP, Reply, length 333
11:10:34.744781 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 8c:85:90:d1:82:a7 (oui Unknown), length 300
11:10:34.806267 IP 172.16.95.123.bootps > 10.250.113.2.bootpc: BOOTP/DHCP, Reply, length 333
11:10:34.806276 IP 172.16.95.124.bootps > 10.250.115.106.bootpc: BOOTP/DHCP, Reply, length 333
11:10:43.396784 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 8c:85:90:d1:82:a7 (oui Unknown), length 300
11:10:43.421706 IP 172.16.95.124.bootps > 10.250.115.106.bootpc: BOOTP/DHCP, Reply, length 333
11:10:43.421717 IP 172.16.95.123.bootps > 10.250.113.2.bootpc: BOOTP/DHCP, Reply, length 333
11:10:53.557959 ARP, Announcement 10.250.112.1, length 46
11:11:31.367397 IP 169.254.175.53.mdns > 224.0.0.251.mdns: 0 [18q] PTR (QM)? _raop._tcp.local. PTR (QM)? _airplay._tcp.local. PTR (QM)? _airport._tcp.local. PTR (QM)? _uscans._tcp.local. PTR (QM)? _ipp._tcp.local. PTR (QM)? _uscan._tcp.local. PTR (QM)? _ippusb._tcp.local. PTR (QM)? _scanner._tcp.local. PTR (QM)? _ipps._tcp.local. PTR (QM)? _printer._tcp.local. PTR (QM)? _pdl-datastream._tcp.local. PTR (QM)? _ptp._tcp.local. PTR (QM)? _companion-link._tcp.local. PTR (QM)? _afpovertcp._tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _rfb._tcp.local. PTR (QM)? _adisk._tcp.local. PTR (QM)? _sleep-proxy._udp.local. (290)

可以看到路由器分配了 IP 给机器，甚至还有mDNS的查询发出，然后就没有反应了。

查了一下苹果分配给 OS预装应用的端口，找到 DHCP 的端口是 68 和 69，mDNS 的端口是 5353，check 了一下，端口都在工作。

于是怀疑是防火墙的问题，关闭防火墙之后果然就好了。但是关着防火墙裸奔也不太好，于是本座把防火墙的配置文件/Library/Preferences/com.apple.alf.plist直接删了重启，这样会让防火墙恢复到原始配置。

重新开机怪事来了，弹了 8 个窗问我要不要放行，都是 configd、netbiosd、mDNSResponder 这类的，不知道 MBP 的同学是不是这个版本搞出 bug 了，这些系统应用需要手动放行。试了一下，放行前果然 DHCP 不能（估计是 configd 和 mDNSResponder），放行后就可以。

值得吐槽的是 Mac推出SIP之后，找个问题麻烦到不行。比如防火墙，默认是没有日志的 ，就算你敲一堆命令下去，拿到的也是个空文件。而它的配置界面上，又很大方的把绝大多数系统应用的设置隐藏了（默认勾选了通通放行），同时又很鬼畜地显示着里面的一两个（比如 netbiosd 和 rapportd）：

Don't touch me

最后，我饶有兴致地查了一下防火墙突然抽风的原因，苹果的说法是：

While configuration changes from migrating or restoring a system can lead to this problem, at other times major system crashes or power outages can do the same.​

所以，电脑上的防火墙还是能关的都关了吧，真需要的话，路由器那边下配置要靠谱得多。

技术团队的绩效提升

上一篇，我们谈了技术团队怎么去进行绩效的度量。通过这些度量可以看到，从行业和我们自己的结果数据来看，提高生产率并不会牺牲质量，相反，产出越高效的团队，在各个指标上会全面领先。并且，好的团队和差的团队的差距在逐步拉开：

Don't touch me

那么，这些指标如何进行提高呢？

文化建设

要通过前面提到的指标来度量团队的绩效，首先需要注意的就是文化。

如果你的团队文化是开放的、学习的，那么用前面那些指标进行绩效的度量才是有效的。Deming在《Humble》里面说过：

“Whenever there is fear, you get the wrong number”。

所以在准备落地这些衡量标准之前，我们要先确认团队有什么样的文化，是否需要改进。

文化的度量

如果你问一个码农，为什么在现在的公司工作，他的回答多半跟文化有关。

但文化是看不见的，要怎么度量呢？我们可以参考北欧社会学家Ron Westrum的模型（相关论文）：

  • Pathological（power-oriented)：屁股大的人说了算。组织里面对信息的分享和流动有恐惧感，会因为政治原因隐藏或者是更改信息。
  • Bureaucratic（rule-oriented）：每个部门都希望能够按照自己的规则来，「自己的」规则意味着厚重的部门墙。
  • Generative（performance-oriented）：关注点在目标达成。如何才能高效的达成目标是唯一的核心诉求。

如何使用这个模型进行文化的度量在行业里面已经有很多可借鉴的实践了。以 Google 为例，花了两年针对 180+个团队的 250 个属性进行的跟踪并且做了几百场访谈，并且把结论和使用的工具都大方公布出来了。

Don't touch me

这些结论里令人印象特别深刻的是：团队里面有没有超级明星不那么重要，而是团队成员间的互动，工作的分工和架构，以及贡献如何被衡量，是最重要的。

贡献怎么被衡量我想特别多说两句，那就是犯错也应该被当成「一种贡献」。在有的组织里，针对问题的 RCA 或者复盘会都会定责到人并且进行惩罚和处分。但我们现在构建的大型系统里，问题通常不是某个人通过自己的专业能力就能预见并且处置和避免的。找到责任人只是第一步，如何让信息被其他人更早的获取？如何提供工具帮大家更好处置问题？这些都是作为技术管理者真正应该关心的事情，也体现了一个组织有没有正确的文化。

最佳实践

John Shook说过：

「The way to change culture is not to first change how people think, but instead to start by changing how people behave—what they do.」

因此要真正的改变文化，除开一些口号，还要真正落实最佳实践。但软件开发领域的最佳实践何其多，究竟选哪些做呢？

实际上Agile Manifesto在 2001 年发布时，XP（Extreme Programming）还正在巅峰。

十多年过去了，我们回头来看，XP 强调的其实主要是一些技术上的最佳实践：测试驱动开发/持续集成/持续部署，而敏捷特别是 Scrum 则主要是一些团队协作和管理方面的最佳实践：怎么开会，怎么计划，怎么验收…从效果上来看，个人觉得技术方面的最佳实践对文化改造发挥的效果才是最大的。

  • 自动化：Manual Work is Bug。机器干重复的工作，人解决有价值的问题
  • 配置管理：可以完全自动化的生成环境，开发/测试/部署流程工具化/自动化
  • 持续部署：让任何变更（新功能/配置变更/bug fix/新功能探索）都能够安全的、迅速地、可持续性的发布到生产环境
  • 持续集成：trunk/branch 能够高效的集成，每个变更能够触发自动 build 和测试
  • 持续测试：在各个阶段都应该有测试。monitoring is testing
  • 版本管理：不仅仅是代码，你的测试环境在不在 git 上？dockerfile 呢？
  • 测试数据管理：不仅仅是自动化测试的数据/现在有工具可以从生产环境录制数据
  • 基于分支的 flow：三个以上的分支就多了，且分支存活应该低于一天（大家都是全职工作不宜使用Github flow，它更适合开源项目，大家都是 parttime，branch 可能需要长期存在），存活时间越短，集成和发布的成本越低
  • 安全和质量：内建的信息安全能力和质量控制，会提高效率而不是降低

有了这些技术上最佳实践的真正落地，员工才有更多的时间花在处理用户问题和重构上，同时也会增强员工对团队的认可度（我在一个很牛的地方上班）。

管理进化

落地了技术上的最佳实践，敏捷流程也像模像样的跑起来了，接下来还需要管理上做一些改变和进化。

服务心态

互联网发展到今天，绝大多数工作，特别是创新性的工作，都是一线员工主导的。作为技术管理者，要有良好的服务心态。这听起来很虚，但其实有很多具体的事情可做。

比如关注员工的Burnout，成立一些兴趣小组，既有放技术委员会里的技术类的，也有体育棋牌歌舞类的。

再比如让变更决策更轻量化：有一些组织进行各种系统变更都需要管理层或者流程层层决策。一方面工作效率低，更重要的是大家觉得老板拍了跟自己没关系，久而久之就认真思考的氛围了。

管理可视化

现在是数据驱动的时代，所有的管理要尽量可视化。

一方面要关注生产环境数据：DevOps 也好，微服务也好，很多这些年看起来的技术风潮，本质上都是建立在一种关注生产环境，关注数据的组织文化上的。

另一方面，哪怕是对内的管理工作，根据自己所在的阶段、团队特点和业务规模时刻确认了指标之后，也要让它变得可视化。要让团队里面的人都有明确的努力方向和荣誉感。

最后，这里提到的各种办法，某一个单一的维度进行提升，对整个团队的提升效果非常有限。就像没有一个好的系统是设计出来的一样，要真正地下功夫提高团队绩效，也需要考虑各种 tradeoff，各个维度的方法组合使用，并且不断打磨和调整。