前言
线上程序已经部署了2周了，一切都很正常。
周五，总是令人愉快的，对不对？上班族嘛，黑色星期一，快乐星期五。
然鹅，我的那个周五漆黑一片。
早上八点多一点，微信就响起来了，顿感不妙，不是来自女人的第六感，那是来自职业的第一感。
果然，是一个工具端同事打来的，噼里啪啦的说，所有的阅片都访问不了啦，你快看看呀，我这边查了日志发你了。
日志大意内容就是无法访问我这边提供的一个服务，这个服务为工具服务提供了关键的数据。
毫无思绪，回忆了一下，我这边最近无任何改动，无任何部署。。。
然后领导的电话轰炸开来，说了噼里啪啦一大片，我说我还有办公小时到公司，现在地铁上。
那一刻，漫长的半小时，我考虑最多的是，我怎么会没有长翅膀呢？
领导的电话不停打进来，他很急，我知道，因为刚好那天老板要给重要客户演示我们的整个系统及设备的运作。天哪！不管是什么原因，我仿佛已经能听到他咬牙发出的咯吱声了。
尽管我下地铁已经用跑的了，但腿真的只有那么长。
到公司，扔下包，马上进入战斗模式。
服务环境：windows2008阿里云服务器、事故程序为 go1.15.5编译的go执行文件
现象：
检查对应的服务发现，程序在启动后不久就会崩掉。
查异常日志，发先每次崩掉之前都在调用C++提供的接口，接口调用失败，程序就崩了
处理办法：
1、先去掉调用C++过程，让服务不崩溃。重新部署上去的程序果然就好了。前线恢复平静，开始分析原因。
2、分析原因。
在此程序中总共调用了2个C++提供的dll程序，本次出问题的是其中一个，另一个正常。两个动态库都已经有半年没有更新，实在想不出为什么。在C++同事分析了一通后得出的结论是：两个动态库编译的环境不同。可能阿里云的服务器在事故前更新了什么鬼，导致其中一个比较老板的vs编译出来的dll出问题了，而且问题原因不明。
后续处理办法：用一个单独的go服务器程序调用C++接口，即便是C++接口出问题了，也不至于主服务go崩掉。
哎！其实还是一个迷，还是一个炸弹。
对于外界来说，我提供的服务又事故了一次。我吃了一缸黄连。。。