一篇不是技术的文章，记录下自己对软件研发中的信任链的思考。
也是最近看一篇监控哲学的文章和参加一场技术复盘讨论有感，这场复盘会笔者听下来觉得最大的问题就是软件研发中的信任链导致的。
软件研发信任链其实在日常研发、交付、使用过程中无处不在，以至于太多人熟视无睹，像我们系统研发就是基于相信spring,netty,openssl这类组件是安全可靠的，也是基于java/JDK是安全的，JDK基于Linux甚至intel CPU是安全可靠的，但实际上他们都有不可靠的时候，比如曾经Intel处理器设计缺陷进而引发的一系列史诗级别的芯片漏洞Spoiler/Spectre就曾经轰动一时，还有OpenSSL的Heartbleed，很难相信这些存在几十年的基础软件潜藏着幽灵，像Spring Data*和SpEL以及Fastjson等都爆出过高危漏洞。
但大部分研发其实不会涉及基础软件漏洞，相信基础软件是大多数研发必然的选择，但研发日常还是存在信任链的，比如以前我们做过一个数据打点收集系统，上游是资深数据分析专家，而下游也是长久不出事故的入库系统，某天数据专家提出数据不对，某时间段的数据量异常，而下游反馈服务无异常。
这个时候我们这一环就处于被动境地，因为下游排查数据丢失是很困难的，要求业务系统证明没有丢数据（服务当机/传输错误/甚至客户端被拦截等），显然我们这时候就丢失了信任链的基础，或许可以将责任递推给下游，但如果我们的有监控数据，能对比五日历史发现曲线其实基本重合的，理论上数据量应该至少也是接近的，这时候僵局就存在打破的可能，好在最后对比几条数据发现是处理方一台机器，有台机器时区不正确导致入库落到错误的partition/表里去了。
如果考虑任何可能，严格地说，大部分系统是无法自证的，大部分监控也是不能自证的，但可以作为参考，或者如果我们比较历史等能让事实更加可信。
笔者认为研发信任链绝不是一无是处，毕竟软件研发就是建立在信任之上的，不论早期unix时各位大神就是信任研发，个人的经历和技术成就本身就是信任的基础，现代研发其实看人/组织的信任链依旧是主流，而且是特别主流的，否则也不会有nodejs病毒包依赖/fastjson漏洞这样影响力（开源简直伟大，又是必然的！）
但不是所有人都是大神，都值得被信任，尤其是那些开发节奏紧促的公司，这时候把信任链产生的错误在可控范围内是共识，所以通常的 压测/灰度/回归/功能测试都是可以很大程度避免的手段，但没有足够的测试时怎么办？
监控，监控，监控！
这也是本文第二个目的，推荐一下这篇翻译的文章：报警的哲学。
不过，技术人很容易主动，我认为这是很难避免的，即便有再多的技术性手段可以约束和规范，总会有人为上的错误，需要经历才能体会，要么经历后从此畏手畏脚，要么经历后学会更多技术性技巧吃一堑长十智，后者就是好的技术人员，提供这样氛围的就是好的技术团队，值得被感恩。
当然除了信任链，更多还需要自己去考虑，比如像把Elasticsearch添加xPack插件做权限校验或者升级Elasticsearch，官方文档给了升级路径，但其实还需要多一步思考，比如可以做到不停机平滑安装吗，不仅ES本身，还有相关应用本身，滚动重启时es各节点正常通信吗，需要停止写入吗，应用本身无认证/有认证的查询请求能正常访问吗。
或许在ES运维/专家看来看到的只是ES安装插件或者升级这件事，多么简单的一件事，官方文档有解决方案，但是对于上层服务提供者需要考虑更多，才会关注服务是否平滑。
我认为上述场景也是一种信任链问题，当系统被划分为多层时，不同层面的人思考关注的问题不一样，并且这种不同有时甚至造成误解。比如上述场景的运维角度看，自己做的就是平滑升级/安装插件这个事，如果应用方也认为这个 平滑 对应用来说也是平滑的，那么这时就产生问题了。
上面问题当然可以通过基础组件提高运维/积累解决方案能力来避免，但那可能不过是诸多问题中的一个而已，笔者就听过有研发听到腾讯Elastisearch运维专家就无条件相信对方的方案，结果做的时候才发现大家对 平滑升级 理解不同。
忘记在哪本书里看过，大型系统开发曾被比作焦油坑，人们困在其中，少数团队爬出来，什么样团队能爬出来？作者列举几个，如水平需要风格统一，要具备稳定性鲁棒性，好维护，细想起来这几点其实围绕的就是信任链问题，风格规范（如maven的约定优于配置哲学）不就是从风格规范提升软件信任度吗，Java/C++等社区提倡的命名规范(如get/set方法不要产生副作用)就更是一种信任链了，如此对后续维护者也是一种承诺。
更一般的，我们对项目研发的进度安排规划本身也是一种信任链，而人月神话作者Brooks提倡的法则：向进度落后的项目中增加人手只会使进度更加落后，或许也和对新加入者的信任度有关。
而接口文档就更是一种软件信任链了，而且更具书面性，更正式，这或许也是为什么程序员不爱写文档的另一个原因，实际上Brooks也对软件手册着重讨论，书中提出了不少不错的建议，总之接口文档是一种信任链，但也是一把双刃剑，其中学问需要多经历和积累。
最后，上述信任链导致ES升级故障的事，其实笔者认为这是一种积极的错误，因为这通常意味着这家公司很可能是在上升发展期，这是有ownership精神的技术员会做的事，相比因循守旧不想大动干戈的想躺赢的技术员，主动性更难能可贵。
遵循CC协议，转载请标注来源