今日手续的完成，标志着我已正式从农行离职了。

关于离职，这是一个思前想后的结果，这是一个艰难的决定。

衷心感谢农行近三年来的培养和鼓励。感谢数据中心各位领导、同事的支持，共同建设运维平台提高生产运维工作效率与质量。感谢2020年在人行数研所借调期间各行同事、各厂同学的支持、协助，在疫情这个特殊时段齐心保障首次数字人民币消费券试点工作顺利完成。更感谢一起码代码、查BUG、做变更的各位大佬们，此生有幸、共愿坦途。

最近半年多一直没有更新过网站了，一方面是近期各种资格考试和培训把业余时间占满了，没来得及总结近期技术积累；另一方面也在考虑行业发展规划方面的事情。

今天这篇，除了告辞，也想简单说一下个人对于目前IT运维，主要以应用与系统层的领域的愚见。

当下IT运维发展，在容器、微服务的大规模使用和传统裸机、虚拟化存量维护的现状下，逐步在技术形态上两极分化：一个方向上，以科技公司、互联网公司和开源团队为主要推动力的前沿技术，将容器与微服务进行规模化、网格化，继而提出了新的运维需求——服务自治、故障自愈、智能监控，因此逐步形成了云原生、Serverless、FaaS、IoC、无代码化等新业务开发和运维方式方法与模式；另一个方向上，传统运维——指纯手工操作占比60%以上、裸机偏多、虚化资源半自动或完全手工等特征——看似没有了领域市场，然而事实上该场景在中小企业、传统行业信息科技事业部等相关职能部门仍大量存在。

一个事物在同一个时刻出现两极分化时，必然会在某个节点选择方向。就应用系统层运维来说，目前节点就是前沿技术发展替代传统方式的爆发起点之时。只不过这个爆发点对于科技互联网企业，早在五年前就启动了。其他领域的传导没有那么快，也是十分正常的。毕竟对于科技互联网企业，技术的革新和快速迭代是他们的主要营收业务，但对于其他企业来说这只是业务支持，按照“互联网黑话”的说法就叫“IT赋能”。

当下前沿技术发展的路径，其实总体来看，是“小而美”的发展策略。要说“小而不美”那是前五年的话，近几年提出的自治、自愈，以及Serverless、无代码化技术的正式投产，是从“不美”到“美”的一种“转型宣言”。一个微服务集群就像是一个城池里的各种角色的人，即亚当·斯密在《国富论》总结提到的工业革命后的社会化分工，每个人在整个社会体系里面专业化的干一件事，将生产力以指数级提升，国民生产总值不断累积加，共同建设发展同一座城池。一个个容器或pods只干一两件事，他们之间相互通讯交流，共同推动了整个业务的正常运转。

在第一次、第二次软件工程危机前的面向过程编程方法兴盛之时，其实这也是“小而美”的时代，但由于业务的发展，单个文件的“小而美”被人为变”大“了。危机后，面向对象编程方法将“小而美”细化到代码内部实现，而对外一个单体程序则是庞然大物。而现阶段的”小而美“则是把代码内部实现和功能最小化，但是放眼到整个系统来看则是把复杂性上升到了系统层面。这么来看，历代软件工程的革新都想从简从美改善，但最终只不过将无序熵从一个领域转为另外一个领域罢了。从这个角度来看，前沿技术或许也不是什么前沿技术，更像是高智商人群设计的游戏规则，各种矛盾转移的”甩锅内卷大赛“。当然，这种看法有点戏谑了。

而这种发展路径，必然将无序熵从开发人员转移到了运维人员。原来的软件工程的开发模式——面向过程到面向对象——是一种开发人员的内部优化，现在的技术革新解放开发人员的同时改变运维人员的工作模式——运维人员也需要相当的代码功底才能做好运维工作，因为一个容器或pod所关联的，仅仅是一个功能，甚至是一个方法或函数的代码，这是一种操作系统与代码强绑定的关系。也由此，SRE发展出了DevOps，DevOps发展出了多个业态方向。

所以，现在的IT运维，尤其是应用与系统层领域，成了一个两面包夹芝士：开发人员由于前沿技术革新，不断提出运维新要求；用户、业务方或领导由于对前沿技术革新并不完全理解，对于运维人员工作内容上的忍耐度越来越低。

解决这样的窘境，可能只有开发运维干一件事才能解决，那就是共同声明：我们联合！

说是简单说点，结果写到这发现扯了这么多。以后公众号将持续更新，去年开的几个栏目：“源产控”系列、“慧响悦书”系列，以及正常的技术总结、日常评谈，都会持续跟进。至于更新频率嘛我尽量完成周更。

所以，没有完全告辞之意就在此了。欢迎关注慧响公众号，一起交流~不见不散~

2021年5月28日 于上海陆家嘴