2024年刚刚过去，我想分享下一个刺激的议题，就是我有幸承担的客户紧急故障救援，由于涉及客户秘密，我不能披露细节，只是想把项目根本原因列出来，方便大家引以为戒。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
其中一个救回了所有虚拟机，令一个因为损坏太严重，只救回了部分
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
虽然合计13个案例，可能没有什么统计上的说服力，但是还是有些参考价值，大家可以在日后的维护工作中可以参考。
作为我个人而言，每当通过自己的操作，将故障的虚拟机修复，客户又可以正常访问这些业务时，我都无比自豪，可能经过一晚的熬夜，没有什么比看到虚拟机启动的画面（如下图）更让人高兴！
（某现场看到的windows 服务器启动的真实画面）
很多时候被请去处理的时候，都未必得到了比较清晰的情况，我也是战战兢兢，除了一次没有什么办法外（也可能是真的没有办法），其他都得到客户较为满意甚至超过预期的结果，一方面的原因是VMware的产品靠谱，经得起风浪，另外可能自己运气还不错，希望能在2025年再接再厉。
有一点我想提醒大家，关于VMware的技术资料这些，在简中环境中，要特别小心，我的一个客户就是看了错误的指引，照着操作，造成了严重的事故；根据我的了解，简中的网上数据能用来进行AI训练的，不到十分之一，因为太多是机器生成或人为操纵，我对某度一直深恶痛绝，大家可以考虑改用微软的必应搜索，选国际版，虽然远不如谷歌，如果能用英文搜索，勉强可用；当然最好还是要以VMware的手册，知识库为准。
之所以将这些分享，是希望客户能参考我分析的根本原因，小心避开坑，这些故障之所以叫做紧急，就是已经影响到了客户的业务，最好策略是能如同和我有长期协议的一些客户那样，多年都没有这种事情发生，其实只要抓住要点，都是能做到有备无患，防患于未然。
如果您觉得有用，请点赞，分享和关注；合作联系电话：13503069419，加微信，请注明vExpert。
原文始发于微信公众号（vExpert）：2024年紧急故障救援总结
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/3600907.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论