进入正题之前，先讲个冷笑话：
说，有个人一天出门，没注意到门口的路上多出来一个坑，结果不小心掉到坑里；第二天他再次出门，又没注意到这个坑，又掉进坑里；第三天，他又掉入同样的坑中；第四天.....
话说，我们如何评价这个人？我想一定是被傻冒、缺心眼、不长记性、愚蠢等贬义词来形容吧？
可是，我没想到的是，我竟然也两次掉入同一个坑中，小丑竟是我自己！呜呜呜，悲伤、愤怒、抓狂、无奈😭
(图源 ：pixabay)
话说两个月以前，我突然发现我的一个很重要的Amazon EC2实例被停止，处于停止状态（“Stopped”），这个实例上我跑着很多重要的脚本，有很多重要的数据。
这个实例和其它实例不同之处在于，我大量的数据和脚本是放到它的本地储存中，而一旦实例被停止，本地存储卷中的数据将会通通丢失：
Any data on local instance-store volumes will be lost when the instance is stopped or terminated.
发现实例被停止后，我研究了大半天才发现是因为Amazon EC2 Instance Retirement被停掉，有关，Amazon是这么介绍的：
An instance is scheduled to be retired when AWS detects irreparable failure of the underlying hardware that hosts the instance. When an instance reaches its scheduled retirement date, it is stopped or terminated by AWS.
既然人家底层硬件都发生不可修复故障了，我还能说什么，退役就退役呗，我只恨我自己没有早早注意到相关邮件，如果注意到了，我就可以提前备份和迁移数据了。
那之后，我用了好久的时间重弄实例、重建数据、重写脚本，等都弄完了，总算大大地松了一口气，总算可以继续躺平了。毕竟用Amazon EC2 N多年，第一次遇到实例退役的问题，而这次迁移后，估计再遇到应该也是多年以后了吧？
没想到，打脸来得如此之快，这两天突然注意到我的一个监控程序显示EC2实例没数据上传过来了，我还以为我前两天维护时忘记启动实例上的对应程序呢。
今天抽空打算处理一下，结果发现实例无法登录，然后进面板看一下，实例竟然又是“Stopped”状态，再进信箱看一样，果然又是前些天发过邮件通知了：
Amazon EC2 Maintenance: Instance scheduled for retirement [AWS Account ID: xxx]
此刻心头有一万头神兽（羊驼）奔驰而过，尘土飞扬！物理机退役可以理解，不过不到两个月，你就再给我来这么一出，实在是太让人愤慨了！
当然，更懊恼的是，自己竟然又掉入到同一个坑中，如果我每间隔一周，刷一下信箱，及时发现这个通知，就可以避免数据再次丢失了！
虽然有了上次的前车之鉴，我备份了脚本，但是所有数据又得重建，而且还得重新修复实例，重新挂载分区啥的。
总之又是一堆事情要做，更悲催的是，现在记性已经不如当年那么好了，两个月前折腾一遍的事情，现在有些茫然不知所措，不知如何下手。
早知道我就写个手册，专门记录遇到这种实例retirement事件如何处理，一步一步按照操作，想必弄起来就没那么难了。
好像上次唯一记录下来的，就是通过Amazon EC2串行控制台（serial console）来解决实例无法登录的问题。也算是自己帮了自己一个大忙，不然又要研究半天查找问题所在，又要去想解决办法了。
网络上有一个梗，类似什么十年前我射出一颗子弹，没想到十年后击中了自己。到我这，大致可以改成，两个月前好心做的分享，竟然帮到了自己。甚是奇妙！
如此一想，好像再次被Amazon EC2所坑，也不是那么难受了，这就是所谓的精神胜利法嘛？感谢阿Q！
(图源 ：pixabay)
好吧，一想到还是突然多了一个麻烦，多出一堆事情要做，还是有些郁闷，呜呜呜，我再去哭一会，呜呜呜。
至于弄实例，恢复数据啥的，明天再说吧。顺便感慨一下，今天沈阳下了今冬（算不算入冬了？）的第一场雪，真大啊。不过一点也不浪漫，晚上放学接孩子，足足耗费了我两个小时的时间啊，累！