横向问题，简单来说就是软件系统内部与业务无关的技术债，比如性能、可扩展性、可用性、可测试性、可维护性和安全合规等问题。这些问题都属于非功能性需求，也就是说，产品经理一般不会把这些问题直接写在需求文档里。
可是日积月累，这些技术债必然会成为整个团队的负担，影响软件的整体质量。这个时候你就要意识到：机会来了！
不过，解决横向问题需要具备相应的专业知识。如果你处在职业生涯初期，每天被业务需求压得喘不过气，哪里有时间去学习研究横向问题呢？
而且，即使你愿意牺牲个人休息或娱乐时间，做选择也并不是一件容易的事情。横向问题有很多，包括性能、可测性、可扩展性、安全等。那么从哪一个问题开始，会是更好的选择呢？还是每样都学一点儿呢？
现在，假设你下定决心要在横向问题上投入精力了，那么接下来要面临的问题就是：学习解决横向问题，该从哪里开始呢？
- 个人兴趣。因为我们肯定要花费个人的休息娱乐时间来学习这个领域的专业知识，提升自身能力的稀缺性。如果没有足够的兴趣，这个过程肯定是不那么愉快的，也很难坚持下来。
- 要考虑商业价值。也就是说，解决这个横向问题能给公司带来多大的价值？给公司带来的价值越大，未来你获得的机会回报也就越大。甚至，公司还愿意花钱来加速你的能力提升。
- 考虑竞争环境，也就是公司内部在这个领域的人才密度。 如果人才供给过剩，那么以你现有的能力和相关教育实践背景，可能很难获得不错的实践机会。在这种情况下，我建议不要在这个领域投入。没有高质量的实践，你的学习很难有用武之地。
无论选择什么方向，都要看清楚自己的相对优势所在。作为一个兼职架构师，最重要的价值就是帮助团队中被某个横向难题挡住的程序员清理路障。你的相对价值越大，获得的实践机会就越多, 横向知识的雪球就会越滚越大。
如果现在还没有特别感兴趣的方向，公司内部的机会也差不多，只是单纯想找一个领域先提升自己。在这种情况下，建议从稳定性开始。
首先，稳定性是任何一个企业都绕不开的问题，是第一性的。企业既然花钱投入了软件研发，最终肯定要做一个稳定的软件。
其次，做稳定性会先让自身受益。请想象一下，如果你写的代码和服务更稳定可靠，就不用半夜从床上爬起来去接报警，活得也更轻松一些。这样才有机会脱离工作的高压，去研究一些更有深度的问题。
最后，稳定性问题和程序员日常代码工作的连续性比较大，你可以一边提交日常需求，一边做稳定性相关的改造。这样一来，获取一些实践机会，几乎不需要任何额外的授权，同时也能从实践中不断获得信心。
稳定性这个话题非常大，一些经验分享如下：
1、 Trust none
代码可靠的原因在于，从来都不要相信自己的代码是在一个可靠的环境中运行。也就是说，任何时候都要坚持检测你的依赖方，确保他们的 API 在以各自所宣称的方式运行。尤其是互联网时代，这是减少故障响应误操作最重要的一环。一旦接到报警，只要检查你的服务，以及相关强依赖的监控与 log，就能迅速排除环境问题了。
2、 Only rely on the most reliable
系统的可用性会随着复杂度的提升而降低。如果想设计一个高可用系统，就必须把依赖最小化。
第一，如果是被迫引入依赖的话，就要选择最靠谱的人和最靠谱的模块。这个结论在互联网行业尤其适用。互联网行业的请求、服务质量、程序员的能力分布，大都符合 Zipf Law 原则，也就是 2-8 原则背后的数学规律。所以一定要选择依赖最靠谱的那一部分。
第二，从管理者的角度来看，在故障出现之前就要锁定那些能真正保护好系统，并且能给出正确判断和方向的人。在稳定性治理这个领域，当所有“聪明”的方法（暗指不借用人力的方法）都用尽之后，还有最后一根救命稻草——人力恢复系统的可用性。所以要不断招聘、培养、训练和保护好具备这种能力的人。
3、Everything decays, especially data
在分布式的世界里，那些简单回滚解决不了的生产环境问题，往往是因为数据配置和频繁更新的代码不匹配而造成的。对于这部分问题，需要把线上系统和可能已经被污染的数据尽量隔开，快速止血。这其实是个设计原则，也就是在设计中要考虑数据污染的情形。如果有多个选择的情况下，应该选择范围更小、可靠性更高的数据来源。
4、When it comes to survival, everything can be downgraded
通过大量的压测和充足的预案，确保一个超高赌注事件能 100% 成功。
5、Availability without cost consideration is bullshit
在中小企业，做稳定性必须要控制成本，而不能因为追求稳定性而牺牲迭代的速度或者大量的现金。在稳定性建设中，要尽量避免完美。世界上不存在 100% 高可用的系统，任何公司也不应该设计 100% 高可用的系统。如果为了高可用，付出的代价是在商业竞争中失败，高可用就完全失去了它的意义。
6、Save yourself!
故障响应的保底原则，意思是先自救。就像乘坐飞机时要求先准备好自己的氧气面罩，然后才能去帮助他人一样。当故障发生的时候，首先要想方设法地恢复自己所负责的服务，不要等待强依赖方的恢复。否则你会沮丧地发现，自己竟然成了木桶的最短板。
横向能力不是积攒得越多越好。公司发展到比较大的时候，相比覆盖广度，横向能力的深度和稀缺性要更重要一些。
此文章为5月Day28 学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。
