终究，还是要为技术债务交税

"本文将分享为什么要为技术债务付出一定时间成本，否则你将付出不可估量的代价"

现状（一）

如果有一天技术老大告诉管理层，最近两周应用不会发布任何新特性，所有技术人员要投入到重构、自动化工作、非功能性需求以及架构优化保证服务的可扩展性、可运维性、可测试性以及安全性等，老板们肯定感觉不可思议，这些一开始不都已经完成了么？

大多企业都对紧密耦合的单体架构深恶痛绝，事实上，在产品生命周期的初期阶段，单体架构往往是最佳选择，它能够快速实现市场和产品的高度契合，当企业用户规模扩大后，这样的架构又存在很大隐患；

但没有一个可以适用于所有产品和规模的完美架构，任何一个架构只能满足特定的一组目标、需求或条件。随着时间的推移、任何产品或者服务的特性要与时俱进；架构也一样，那些在普通规模下设计的架构，很少能在10或100倍用户下继续有效。

如何改变这种现状呢？（二）

    对于不重要&不紧急的事情，都非常清楚，下班时间看电视刷抖音，干不干都行的事情；

    不重要&紧急的事情，快递员打电话让你领快递，自己没时间就找个人带领了；

    重要&紧急和重要&不紧急事情，常常容易混淆，一般情况下都忙于重要&紧急的事情上，产品要发布新功能，凌晨上线，要做好万全的准备，这是重要的事情；是否考虑过自动化运维管理平台，通过金丝雀发布、灰度发布在保证服务可用情况下，任何时间任何人都可以完成上线，这就是重要&不紧急事情；这些事情常常容易忽略。再说了，谁能保证凌晨的技术人员不犯傻呢？

    面对当今复杂多变的互联环境，老板们的心态也应该有所改变，愿意为技术人员研究不可见的功能特性留出一定的时间。

    对于程序员在做系统设计和编码时尽量保证各个版本之间都能向前或者向后兼容；输出容易轻松理解和搜索的业务日志；一个阶段开发完成后要考虑安全性检查，如web站点攻击、XSS攻击、sql注入攻击等，这些事情如果非要挤压到一定程度再去解决，很可能会出现不能修改或者修改需要付出更高代价；

    就现阶段技术环境而言，测试人员的编码逻辑能力普遍比较弱，但对于自动化测试脚本开发却需要比程序员更强的编码或者逻辑思考能力，如果自动化测试脚本本身出现问题，会带来更严重的问题。所以就出现了，每次产品发布前点来点去，发布后还要点来点去，发布下个阶段功能时，不仅如此，还要把上个阶段点来点去，在这种漩涡里，愈演愈烈，没有时间编写自动化测试脚本，看似忙的不行，其实是组织过程效率低下的表现。对于这种问题，测试人员可以尝试对不经常变动部分脚本化，或者采用补偿机制，当某个服务经常出现问题时，对这部分服务单独使用自动化脚本检测。通过自动化脚本建立快速反馈机制，提高测试和发布效率。

    对于运维人员更多是自动化平台的搭建和管理，而不是人肉运维。具体参考之前写的：云时代的运维正是不折不扣的架构师

所见耳闻（三）

关于最近几天微盟技术故障问题，吃瓜吃的沸沸扬扬，各种消息扑面而来，暂且不论事情结果怎么样吧，网上出了很多防删库指南，【数据备份很重要，最好两地三中心】【最小权限原则】【跟公司出现矛盾时候，不要一时冲动干傻事】......

2018 年顺丰就因为运维人员不谨慎操作，导致服务停机长达十个小时....

2017年1月31日，Gitlab一名系统管理员误删库，发现问题300GB左右的数据只剩下约4.5GB。经过抢救，GitLab.com最终丢失了6小时的数据库数据。

这种事情发生的还少吗？其实过去了就过去了；就像平时出现问题的临时解决方案，大多是永恒的。

删库这种事情，可能是是拖欠工资、也可能是心生怨恨、更可能是一时糊涂或手误，研发人员有几个没有做过误删除操作的，当年我就是一个rm -rf /*把公司测试服务器数据全格式化了。

删库这种事情，在我看来跟公司线上环境出现明显漏洞、服务崩溃，从性质上来说其实没什么两样，都是前期没有做好准备。

个人认为出现这种问题，警示其它没有出现问题的公司，要做好备份，控制好权限，一般没人搭理你，做备份物理机或者云服务器你出钱买吗？线上服务出现明显漏洞被灰产割羊毛了，抓紧时间定义开发、发布、测试、部署流程杜绝此类问题再次发生。对于市值几百亿的公司，尚且如此。那么对于一些中小型互联网公司呢？优化发布流程，学习研究自动化平台，不要逗我了，需求能做完吗？公司是要考虑成本的，这么多人整天优化流程、精简代码，这些不可见的非功能性需求能换成钱吗？

总之对于当前有一定价值的服务或数据，心里有点数就行了。