昨天在群里看到一小段对话，大意是因为技术原因运营的同事遇到了紧急的问题，我们技术说，依赖的服务出了问题而实在太晚相关的技术已经休息找不到只好等明天。运营的同事不知道是无奈还是理解，最后接受了。
抛开这个问题是否真紧急到必须即刻处理不说，事件本身反映的是更深的问题：即作为技术，我们应该怎样处理业务方反馈的问题。
1. 首先是技术问题，怎么把自己的系统做得更有弹性，即依赖的服务出问题时，我们也能尽量不中断业务，至少让业务人员知道是怎么回事，而不是惊慌失措。比如做好自动监控和报警。比如本地数据有AB两份，一份用来从更新远程，更新成功后再切换等。这依赖业务，不能一概而论，而且也要看代价。还可以采用的做法是给业务方合理的提示，比如告知他等会再刷新，而不是直接出系统错误。
2. 其次是问题响应机制，不应该出现有问题时找不到人的情况（这次不是因为这个原因），沟通渠道应该畅通，响应制度应该完备。比如分响应级别，什么类型的问题需要即刻找到人处理，什么问题虽然很着急但可以晚一些处理等等，应该有基本的标准。另外，有必要的话可以有值班小组，来分辨问题级别，并且进行调度。
3. 再者是沟通问题，换个角度，如果我是业务方，火急火燎的问题别人跟我说太晚技术休息的时候，我也会很恼火，尽管嘴上客气。不信可以试试不同部门之间打满意度，恐怕能说明问题。不满是各种小问题累积起来的。
4. 最后是技巧问题。人力原因，不可能24小时随时有人响应问题，但问题不会考虑人在休息就不出现。为了融洽各部门，那就应该在重要问题时快速响应，持续改进产品，提升服务可用性。日常遇到问题时，则控制好节奏，攒一批问题再处理，避免被频繁打断。借用“峰终原理”，在产品开发资源有限的情况下给业务方制造好的体验。
5. 最后，复盘总结是非常重要的工作方式，总结需要告知各业务方，不要自己聊完就完了。
6. 技术面临的最大问题其实都不是技术问题。
