参与调试的架构师 - Gregor

23-01-09 banq

架构师是否必须编码,已经有了很多争论。为什么不尝试调试?

架构师喜欢做错事
架构师必须定期测试他们的假设,如果他们发现其中一些假设是错误的,他们必须感到高兴--这就是我们保持相关性的方法。


调试
系统告诉我们错误的一种奇妙方式是调试(包括运维问题的故障排除)。当现实偏离你的意图时,调试就会发生,也就是说,你在某些方面出了错。现在的任务是弄清楚你错在哪里了。这意味着调试中最快乐的时刻就是你发现你错在哪里的时候。

调试中最快乐的时刻是发现你错在哪里。

架构师通过调试系统,代替了(或补充了)编码,收获颇丰。

低开销
帮助开发者进行调试时,几乎没有设置或开销。开发者会有一个IDE和所有的工具设置,大多数可观察性工具由于其性质,是运行的子系统,不需要单独设置或配置。这意味着你可以快速进入调试环节,为团队提供价值。

专注于关系
架构的大部分内容都是关于线条的,也就是元素之间的连接和依赖关系。而 "盒子",即单个组件,通常是经过良好测试的,不太可能成为问题的来源。这就是为什么许多错误,特别是运行时问题,是元素之间复杂的相互作用的结果。不出所料,这也是系统架构的领域。现代架构师不需要告诉开发者每个方法允许多少行代码,或者什么时候使用Singleton。相反,架构师关注的是整个系统的结构,并确保在面对负载、需求或环境的快速变化时的可靠运行。

小变化,大影响
调试工作的结果通常是大量的思考,然后是一个小的代码或配置变化。这就是为什么它是架构师的一个理想任务。对架构师来说,编写几行代码并不是最有价值的活动。但了解系统结构和隐藏的依赖关系才是最重要的,而调试就是关于这一点。

超越层次
架构师电梯的关键概念是跨越层次,从IT和商业战略一直到技术细节。调试确实需要你深入研究。最伟大的调试故事之一是Jeff Dean和Sanjay Ghemawat通过观察二进制格式的数据来检测硬件相关的故障。

偶然性
作为架构师,我们喜欢结构化的方法和思维。调试的工作方式正好相反:系统把你带到一个你没有充分注意的地方。因此,调试是了解系统角落的好方法,否则你可能会忽略这些角落。

即时增值
编码对架构师来说是一项有用的工作,但它也与开发人员的任务和性能指标相重叠。编码架构师可以被看作是对团队的帮助,但也可以看作是越过了自己的界限。相比之下,对调试或生产问题的帮助,几乎总是受欢迎的。而且这肯定比管理层要求更新故障信息要好。帮助开发人员排除故障可以为你在机房赢得一些非常有用的友谊。