中文
9月10日，深信服从应用交付产品视角出发，以“务实求效，运维避坑”为主题举办线下交流活动，来自金融行业的运维技术专家及cto就运维中遇到的挑战与心得展开了交流与分享。
对于用户的数据中心以及业务架构而言，应用交付产品是位于枢纽的重要“调度员”。它既是应用访问的唯一入口，也是数据中心的访问出入口，还是dns解析的关键环节。可以说，应用交付产品的会直接影响业务和服务水平。而应用交付产品的运维，需要面对较高的技术门槛，多样化的业务场景，千奇百怪的故障现象，想要真正运维好应用交付产品是存在挑战的。
为此，我们根据此次活动运维专家们的实战经验进行总结，整理出应用交付视角下的运维避坑指南，帮助用户避开日常运维的“那些坑”。
虚拟服务故障类型繁多，无从下手？——明确故障现象
虚拟服务发生问题，业务上的故障呈现会千差万别，最重要的一点是明确故障现象，而不是直接上手解决。比如，是出现了404还是503？全部不能访问还是部分不能访问？明确现象可以快速理清思路找对应的解决方法。如果确定是应用交付产品的问题，则进一步检查产品配置信息，并对网络环境配置信息进行逐一排查。
一系列的优化举措，无法生效？——精准匹配业务需求
业务的种类和需求越来越复杂，这些需求衍生了很多优化策略，比如基于url的调度，ip的调度、基于请求或应用的改写等。然而很多情况下，这些策略并未真正满足具体的场景化的要求。对于此类问题，第一步要做的是明确优化策略是否精准匹配了业务需求，并明确与之相对应的凯发登录的解决方案，避免南辕北辙，当两者确定以后再进行配置上线，避免因为策略匹配问题导致上线失败，最后抓包验证优化策略是否生效。
ipv6改造失败或故障频发？——确认网络改造环境
在相关政策驱动下，越来越多的应用需要进行ipv6改造，但是改造过程可能会面临大量外链并涉及天窗等问题。对于ipv6的改造之前，要明确改造环境以及改造需求，比如现有的域名体系不支持ipv6，改造就会出现问题。环境的差异问题可能导致改造失败，需求的不明确会导致做无用功。此外在进行ipv6改造以后也会搭建环境进行验证，为避免问题反复出现，在测试阶段就尽可能多地发现潜在故障并进行解决。
链路负载均衡故障处理难度大？——找准应用及前后端地址
在面对链路负载均衡故障的时候，首先依然要明确故障现象，比如是选路错误？还是核心业务页面无法访问？还是不同链路流量分配不均？由于部署了链路负载的设备放在数据中心涉及大量的流量，排障不可能对所有的流量进行抓取，所以需要根据故障现象找准故障应用和前后端地址，然后再依次确认链路状态和配置进行排查。
全局负载均衡难以实现？ ——明确dns解析需求
全局负载均衡问题一般是双活数据中心或多活数据中心建设过程中遇到的解析问题，即智能dns，智能dns可以将客户端需要访问的域名解析到不同的数据中心、不同的线路上，需要明确dns解析的具体需求，到底是基于区域的还是基于运营商的，或者两者皆有涉及，又或者是基于客户自定义的策略。根据具体需求来确定凯发登录的解决方案，配置，并进行验证。
采用主备集群模式部署故障频发？——逐一确认配置正确性
首先要明确设备是否满足集群的主备条件，比如对于应用交付设备而言，版本要一致，接口要一致，型号要一致。另外要确认主备心跳口是否正常以及主备配置及故障切换条件是否正确，主备部署之后会设置各种各样的切换条件，比如网口故障、节点故障，甚至和防火墙等进行联动，所以要逐一确认是否为正确的配置。之后便是确认网络环境的互通性及连通性等是否能够达到要求，并对主备故障日志进行分析。
除了以上运维实战经验总结，深信服应用交付ad还提供了一系列的实用工具帮助用户进一步提升运维效率。
acheck巡检工具：用户对于设备入网都有相应的安全标准，acheck可以在设备入网之前对安全基线进行检测，并给出优化意见。同时可以对节点状态、业务进程、告警日志信息等进行自动巡检，并输出巡检报告，以消除潜在风险。
系统黑盒：可以将设备在某一时间段内的运行日志全部记录在黑盒之内，以便在遇到复杂问题需要排查原因时，为排错提供有效依据。
webconsle：能通过web页面进行命令行操作，更便捷地查看地址、端口、协议等连接信息，同时一键检测设备进程信息，提升排障效率。
配置转换工具：在进行设备替换时，功能参数复杂，很容易出现遗漏导致错误，通过配置转换工具，只要能达到之前设备的要求，就可以输出对应的应用交付ad设备的配置，大幅简化运维工作量。
对于应用交付产品，最直观的理解便是将应用以更高的质量和效率交付给客户，在这一过程中，不应出现运维短板。希望这份运维避坑指南帮助用户释放精力，提升效率，以更完善的运维为业务发展提供坚实的支撑。