探析未备案域名带来的系统故障：深入剖析业务团队与阿里云多次提醒后，由于法人变更流程未完成，域名无法备案的情况。本文详细回顾了由于域名未备案所导致的系统故障，包括问题的分析、定位以及紧急处理。这个案例凸显了域名备案的重要性，同时也揭示了如果因此产生的潜在风险。对于在域名管理和故障处理领域寻求洞见的读者，本文必将提供有价值的观点。

[toc]

注: 因公司相关保密信息，相关域名及敏感词汇用xx代替;

关于某业务线域名未及时备案导致的故障与脱机报告

以下是对接的开发第一时间反馈的故障图

因教师XX-APP及服务器部署环境架构由XX技术团队独立搭建，交接给XX中心仅做正常运维保障，教师XX业务一直进行中。XX、购买、XX系统、XX系统…未停止，且xx部人力投放在其他大项目中开发和维护。

问题的反馈

于2019年09月03日晚对接的相关业务部门反馈教师相关线务业的网站和接口不能访问与调用超时；
研发对接的相关接口如上图，当对接的业务线的开发反馈时，说可能与上次故障Cassandr 数据库未能正常访问类似;
在运维组与部门总监未曾沟通协作的情况下，负责对接此业务线的相关运维将问题暂定到Cassandr 数据库上;
9月4日上午8点多，研发部和运维组同学协同查找问题，最后发现xxx.xxxteacher.net;未在阿里云备案，导致域名失效无法访问的结果。

故障总结

由于xxx.xxxteacher.net未备案导致被阿里云拦截后无法请求到数据库，实际上当时数据库正常运行。
运维组对应业务线的同学接到保障以后第一时间处理，发现系统并无异常，但一直无法访问，无法恢复。
运维同学未能想到是域名的问题，以为是数据库应用无法处理请求的未知故障，所以尝试重启数据库。
因为此数据库之前一直由福建方面单独维护，大量参数设置问题，导致数据库加载过慢。
运维组同学尝试迁移，但发现XX团队申请时的数据库的服务器不在集团的集群之内，数据量太大所以放弃。
运维组连夜尝试恢复数据库应用，但都是显示系统日志正常，Cassandr未能启动，直到后半夜未能找到解决原因。
早上升级了数据库二进制文件后成功启动。然后进行接口测试时发现请求不到的原因是域名被阿里云禁止，接着通过Nginx域名转发与反代技术恢复了业务。

业务核心问题

域名没有备案，主要原因与教师业务线团队沟通是因为法人变更流程没完成，导致无法备案。
数据库重启后恢复过慢，这是由于应用架构是福建团队搭建，当时独立于运维组，运维组对这个数据库系统不熟悉，并且原方案中没有高可用性，致使数据库单点失败。

XX中心紧急处理方案

当时业务线对应的研发技术团队，在上午定位到问题后，技术总监曾沟与个人沟通，能否有什么办法先尽快恢复生产的服务器;
经思量、因阿里云DNS结合阿里云公网IP扫描到未备案经需数小时的时间，而若扫描别的云平台公网IP与别的公网ip需要数十天，甚至数月的时间;
故~ 考虑公司有相关IDC机房的多个公网IP，可以将公网ip映射至现有的keepalived虚拟ip;
并将keepalived 上的nginx 添加一个虚拟主机的配置文件，使用nginx 反向代理的方法再代理至原有的业务线所在的各阿里云的服务器私有ip(因公司内部有专线，若无专线的情况下，可以考虑直接反代至阿里云的公网ip，但在反向代理的时候不对host 请求做转发)；
最后在测试无误的情况下，对应的域名解析做变更，解析至公司IDC公网ip;
最终于上午10时20分左右，相关域名的整体业务线恢复访问。

领导后续重点工作安排

教师XX-xx部xxx继续对域名备案，进度实时通知到XX中心。
XX中心将对教师xx阿里云服务器架构多部署新一套负载服务器环境及数据备份，完成时间：2019年9月13日。

责任鉴定

教师XX-xx部-xx 掌握阿里云域名管理，域名管理不善，阿里云已多次提示域名未备案，未曾及时反应;
运维组对教师xx保障服务器运维处理存在判断有误，未能积极组建问题处理小组群,并及时通知大家寻求帮助与协调处理;

故障后感

做为技术人员的我们应该对我们的技术专业有深入的理解，在判断到是大的问题或故障时需及时主动协调部门人员与寻求帮助;
不断的积累各项运维架构技术与学习各个应用的场景;
不断积累曾遇到的问题、与故障的处理经验、并标准化且规范化录入文案;
遇到问题时，不要着急，需冷静且快速的定位问题，要明白打不倒你的终将使你变得强大;
感慨nginx 功能之强大，还需要深入研究。

文章发布后也愿能提供给更多公司的技术团队一些经验与帮助

补充nginx 反向代理的配置

upstream xxx.teachxxxx.net {

    # 这里就是要反代的阿里云ip与端口
    # 相当访问中间加了一层
    server xx.xx.xxx.xx:xxxx;
}

server {
    charset utf-8;
    listen xxx;
    server_name xxx.teachxxxx.net ;
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # 注类似这样的故障，host 不再转发，不然还会被检测到
        proxy_buffer_size 64k;
        proxy_buffers 32 32k;
        proxy_busy_buffers_size 128k;
        proxy_pass http://xxx.teachxxxx.net;
    }
    access_log /var/log/nginx/xxx.teachxxxx.net.log;
    error_log /var/log/nginx/xxx.teachxxxx.net.log;
}

注，至于平常生产中的443转发的实现，可参考博客中其余的nginx配置

server {
    listen 80;
    server_name xxx.teachxxxx.net;
    return 301 https://$HOST$request_uri;
}

补充 nginx 匹配?后面的参数，做精确匹配与屏蔽接口攻击

location ~* "/News/NewsDetail_New.aspx?" {
    default_type text/html;
    add_header Content-Type 'text/html; charset=utf-8';
    if ($request_uri ~* "NewsID=57180") {
        return 200 '<h1>ok!</h1>';
    }
}

其余系统应急恢复与该配置的实现类似

关于某业务线域名未及时备案导致的脱机故障与报告