郭东白的架构课_48_37能力维度二如何提升解决横向问题的能力
你好，我是郭东白。
上节课呢我们讲的程序员的结构化设计是成长为架构师的基础能力。
那么如果想正式开始，你的架构师职业，该从哪里开始呢？这节课呢我们就讨论一下这个话题，我们先研究一下程序员和兼职架构师这两个角色的区别。
在软件架构这个上下文里，程序员指的是能够结构化的完成业务需求的一线管理工程师。
在软件架构这个上下文里呢，兼职架构师指的是呢能够解决自己负责领域的横向问题的软件工程师或研发管理者。
在定义的描述中呢，我们还能轻松的看到两个角色的差异。
主要在横向问题上。
也就是说呢，兼职架构师这个角色，除了需要关注自己的代码之外，还要关注横向问题。
横向问题简单来说就是软件系统内部跟业务无关的技术债。
比如说性能可扩展可扩展性、可用性、可测试性可维护性和安全合规等问题。
这些问题呢都属于非功能性需求。
也就是说呢，产品经理呢一般不会把这些问题直接写在需求文档里。
技术债的产生呢一般有两个原因，一呢是你跟周围的同事在横向问题领域里面呢存在认知盲区。
第二呢是由于日常研发过程中的优先级取舍，导致一些技术债呢被短期搁置。
可是呢日积月累，这些技术债呢必然能成为整个团队的负担，影响软件的整体质量。
这个时候你就意识到机会来了。
那么怎么把握住这个机会解决这些技术债的问题呢？我们在模块导入中提到了从程序员成长为兼职架构师，需要跨越的主要障碍，就是责任边界。
从上节课的习惯性思考一样，责任边界呢也属于意识和习惯上的问题。
解决横向问题的，并不是你这个研发人人员的责任。
毕竟呢很小的公司呢会配备专属的研发资源，多数人呢都没必要突破自己的责任边界，去解决公司的横向问题。
所以呢你必须要找到一个能能对日常研发任务形成促进作用的支点，来帮助自己突破这个障碍。
不过解决横向问题呢需要具备相应的专业知识。
如果你处在职业生涯的初期，每天被业务需求压得喘不过气，哪有时间去学习研究横向问题呢？而且即使你呢愿意牺牲自己的休息和娱乐时间，做选择呢，也不是一个容易的事情。
横向问题有很多，包括性能、可测性、可扩展性、安全等等。
那么从哪一个问题开始会是一个更好的选择呢？是不是每样都学一点呢？不过此时呢你可能还面临一个更急迫的选择，职业生涯刚刚开始，业绩考核压力山大，日常研发工作都已经很吃力了。
那么你是应该优先提升日常研发的能力，还是分一部分精力去提升横向能力呢？类似这样的选择，在架构师的职业发展中呢，有很多都需要我们做出良好的取舍。
我们接下来看看怎么跨越从程序员到兼职架构师的障碍。
我们先讨论这个最迫切的问题。
如果日常研发都很吃力，我应该分出精力去研究横向问题吗？但是不应该的，你想想看，如果连日常研发工作都做不好，甚至还有可能在下一批被淘汰的候选人名单里。
在这种情况下呢，上级是不可能把任何有挑战的横向问题交给你的。
所以你的首要任务一定要先把日常的研发工作做好。
那么如果你有额外的精力，那你是应该花精力在提升本职工作的深度，还是分一部分精力去提升解决横向问题的能力呢？这呢是一个好问题，好像我在考编子里面提到的。
如果你的战略意图呢是做一个优秀的架构师，那么这个问题的答案是肯定的。
当然呢如果你志不在此，那么解决横向问题就不是最好的选项。
对于这个问题呢，我们在模块呢我们化商业价值这个法则里面呢有些探讨，你可以参考一下。
现在呢假设你下决心在横向问题上投入精力呢，那么接下来面临的问题是学习解决横向问题该从哪里开始呢？在这个决策的过程中呢，我一般会从三个方面来综合考虑。
最先呢是个人兴趣，刚刚开始的时候呢，我认为个人兴趣最重要。
因为我们肯定要花费个人的休息娱乐时间，来学习这个领域，提升自己能力的稀缺性。
如果没有足够的兴趣，这个过程肯定是不那么愉快的，也很难坚持下来。
第二呢，是要考虑商业价值。
也就是说呢，要解决这个横向问题，能给公司带来多大的价值，给公司带来的价值越大，未来你获得机会回报呢就越大，甚至呢公司愿意花钱来加速你的能力提升。
最后呢你还要考虑竞争环境，也就是公司内部在这个领域的人才密度。
如果人才供给过剩，以至于你现有的能力和相关的教育时践背景，因认获为不错的时间机会，那我建议议不要在这个领域里投入入为没有高高量的实践，你的学习就没有用武之地。
无论选择什么方向，你都要看清楚自己的相对优势所在。
我再强调一下，是相对团队其他同学的优势。
你作为一个兼职架构师，最重要的价值就是帮助团队中被某个横向问题挡住的程序员清理路障，你的相对价值越大，获得的实践机会就越多，横向知识的雪球就会越滚越大不过呢。
如果你现在还没有特别感兴趣的方向，公司内部的机会也差不多，只是单纯想找一个领域先提升自己。
在这种情况下呢，我建议先从稳定性开始。
我们接下来呢探讨一下这个问题。
为什么我建议从稳定性开始呢？首先稳定性呢是任何一个企业都绕不开的问题是第一性的企业既然花钱投入了软件研发，最终肯定要一个稳定的软件。
其次呢做稳定性呢会让你自身受益。
你想象一下，如果你写的代码和服务更稳定可靠，就不用半夜从床上爬起来去接报警，或得也轻松一点。
这样呢才有机会脱离工作的高压，去研究一些更有深度的问题。
最后呢稳定性问题和程序员的日常代码工作的连续性比较大。
你可以一边提交日常代码需求，一边做稳定性相关的改造。
这样一来呢，你获取一些实践机会的时候呢，几乎不需要任何额外的授权。
最时呢也能获得一些时间的信心稳定性。
这个话题呢非常大，将来有时间呢我打算专门起个专栏来讲。
那今天这门课呢，我先把之前总结的经验分享出来，当时是用英文写的。
这里呢我先加上一些简单的中文注释，第一条原则呢是trust now.意思是呢永远不要轻信别人的话，也就是说呢你依赖的服务不会返回他们应该返还的东西。
写代码检查依赖远远比第bug代码容易的多。
这条法则呢同样适用于安全问题第二条，原则呢是only rely on the most reliable.意思是说呢，如果你必须依赖一个人或者一个服务的话，只可以依赖那个最可靠的人或者是服务。
第三条原则呢是everything decades, especially data.意思说呢所有的东西呢都会过期变质，尤其是数据。
也就是说呢，你拿到的数据配置服务消息，但通知都可能过期。
你给别人的数据也是一样的。
这些数据可能在过去某个时间点是有效的，但绝对不是现在第四条原则是呢？When it comes to survival, everything can be downgraded.意思说呢，在生存也就是维持系统的可用性面前呢，所有依赖都可以被降级。
第五条原则是availability without cost, consideration is bullshit.意思是说呢我考虑成本的稳定性就是耍流氓。
第六条原则呢是save yourself,意思是说呢猪队友呢永远是在你最最危急的关头出现。
关键时刻呢你要有能力保护你自己。
你可能问这六条原则好使吗？从个人的经验来看呢，的确是好使的这是一个相对成熟的互联网企业员工所沉淀出来的稳定性、生存的实用指南。
每条法则呢都是靠大量的真实案例训练出来的。
多年前呢，我在亚马逊工作的时候呢，我阅读了四百多条p零故障的复盘，发现其中的百分之八十以上的故障呢，靠这几条法则就能完全避免或者快速恢复。
我来剖析一下这六条经验原则的大致出处和背景，以及他们曾经给我带来的价值。
第一条原则呢是trust down,主要呢源于我在甲骨文工作期间呢，公司要求人人都要学习代码安全规范。
我这里呢也包含defensive coding的核心理念。
这条原则呢基于一个非常重要的认知，那就是代码可靠的原因是你从来不相信自己的代码在一个可靠的环境中运行的。
也就是说呢任何时候呢都要坚持检查你的依赖方，确保他们的API都是在他们意义他们自己宣称的方式来运行。
尤其是互联网时代，这是减少故障响应误操作的最重要的一环。
一旦接到报警，只要检查查的服务，还有相关强依赖的监控控log就随速速杂排环环境题题了。
第条条则则是only rerely on most.这呢来自系统工程学科的中中间的一个结论，也就是系统的可用性会随着复杂度的提升而降低。
如果你想设计一个高可用系统，你就必须把依赖最小化。
除此之外呢，从这句话呢，我们就可以引申出两个结论。
第一个结论呢，就是如果你要被迫引入依赖的话，你就选择最靠谱的人和最靠谱的模块。
除个结论呢，在互联网行业，尤其适用互联网行业的请求服务质量。
程序员的能力分布大都符合zif long原则，也就是二八原则背后的数数学规律。
所以一定要选择那个最靠谱的部分。
第二个结论呢，是从管理这个角度来看呢，要在故障出现之前，锁定那些真正能保护好你系统，并且能给出正确判断和方向的人。
在稳定性治理这个领域。
当所有的聪明方法都用尽之后呢，还有最后一根救命稻草，那就是人力恢复系统的可用性。
所以呢要不断的招聘培养训练和保护好具备这种能力的人。
所以这句话呢也是对稳定性响应原则的总结。
第三条原则呢就是我从亚马逊工作经验中总结出来的。
在一个分布式的时间里，那些简单的回滚解决不了生产环境的问题，往往是因为数据配置和频繁更新的代码不匹配而造成的。
对于这部分问题呢，需要把线上的系统和可能已经被污染的数据尽量隔开，快速止写。
其实这是一个设计原则，也就是在设计中呢要考虑到数据污染的情形。
如果有多个选择的情况下呢，你应该选择范围更小、可靠性更高的数据下呢，第四条原则呢是以对马马逊的d day,还有阿里双十一高可用性保障方法论的总结。
也就是呢通过大量的压测和充足的预案，确保一个超高堵著的事件能够百分之一百成功。
这个话题呢，我们在模块二的可行性探索环节里面有详细的解释，我就不再重复了。
在五条原则是我这些年对一些公司过度稳定性建设的建设的反思。
更多呢是从中小企业的CTO的视角来重新审视稳定性的投入。
在中小企业或者呢是在一个大公司里面的小部门做稳定性呢可行，要控制成本，而不是因为追求稳定性而牺牲迭代的速度，或者大量的陷阱。
有稳定性。
建设中呢要尽量避免完备，世界上呢不存在百分之百高可用的系统，任何公司呢也不应该涉及百分之百高可用的系统。
如果为了高可可用付出的代价是在商业竞争中失败，高可用呢就完全失去了它的意义。
最后一条原则呢是故障响应的保底原则。
意思是呢先自救，就像乘坐飞机的时候呢，要求先准备好你自己的氧气面罩之后再去帮助他人一样。
当故障发生的时候，首先要想方设法的恢复你自己所负责的服务，不要等待你强依赖方的恢复，否则你会沮丧的发现自己竟然成了牧桶的最坦板。
你可能会问呢，怎么没有从头到尾的稳定性捐设方法呢？这似乎不完备呢。
监控、报警建设都没有提降级、限流、监控、报警等稳定性的常规手段，在多数互联网公司都已经齐备，甚至在互联网早期不齐备的时候，我也不会把这些手段当成原则。
因为这些是手段。
原这个价值呢在告诉我们如何去做取舍，丢车保帅，而不是面面俱到。
我的职业发展过程中呢，做稳定性就是靠这六条原则来保密的。
前面也提到了，假设你所在的公司里呢，已经有不少稳定性的大拿或者所处的环境中没有较多的稳定性机会，你就应该选择其他的横向问题中去提升。
除了稳定性之外，我认为性能的优先级也比较高。
主要呢是商业回报，容易量化，也容易跟日常工作形成正向促进。
此外，做性能也可以对自己的代码和公司的业务更加熟悉。
横向问题呢其实有很多横向观察是多数研发人员都不缺成长的机会。
缺的呢往往是意愿，只要平时不断积累，主动解决问题，机会呢永远比竞争多。
最后我要强调一点，横向能力呢不是积攒的越多越好。
公司发展的比较大的时候呢，相比于覆盖广度，横向能力的深度和稀缺性更重要一些。
好了，今天的内容呢就是这些，我来简单总结一下，像生活中的很多事情一样，从程序员过渡到架构师，需要有足够的意愿和投入。
具体怎么做呢？我相信随着技术的变化也会一直发生变化。
因此呢在这个过程中，你的主动规划更重要。
我们在课程中介绍的方法呢，简单来说就是最大化LI的策略。
之所以建议把兴趣放在第一位，就是因为兴趣会帮助你最大化投入度，而投入度最终呢会带来能力的稀缺性。
如果你是一个利益驱动的人呢，那么回报就决定你的投入性。
回报呢是解决横向问题带来的商业价值决定的人才。
供给的竞争呢则是市场人才市场呢对回报的自然反应。
也就是说呢，市场会带来人才供给的弹性，高回报的场景呢，必然会有更多的人才涌入，最终回报和投入趋于理性。
但不论如何，你的兴趣却可以让你以更大的投入来维持你自己的稀缺性。
我们后面的课程呢还会介少你如何跨越其他障碍的方法。
其实呢策略雷同，我就会再重复今济的描述了。
我在这节课呢还分享了我自己总结的稳定性法则。
正如我们在模块一里反复强调的，我分享他们的目的呢不是让你去记忆，而是请你也尝试用同样的方法在工作中不断的总结，然后用你发现的案例去修正他们。
我也期望你把反例分享在这里，我们一起讨论提升。
最后呢依然是三个作业，你可以选其中一个，做一下。
和上次一样，目标呢不是做的全，而是做的深，做的有感触。
欢迎呢把你的想法分享给大家。
第一个作业呢是如果你曾经跨越过从程序员到兼职架构师这个障碍，你能分享一下你最大的心得吗？第二个作业，请思考一下，你现在团队里面的横向领域中最大的机会在哪里？为什么会是这个机会呢？其他人扑上去了吗？第三个作业，请总结一下最近半年你遇到的稳定性的重大问题，有哪些？稳定性问题不能被我提到的六个原则。
所解决的。
如果要增加一个原则，你的建议是什么？如果要删除其中的一条原则，你会删除哪一个？为什么？欢迎你把你的思考和想法留在我留言区，我会和你交流。
我也欢迎你把课程分享给你的朋友，同时呢我们一起进步。
我也欢迎你关注我的抖音号咕咚版，那里有一些挺好玩的东西，我们下次再见，拜拜。