简写两笔感悟，有空下次再续。
首先从管理上来看，在驱动安全落地的两种方式中： 事件驱动 和 管理驱动 中，重保是一件极为有利于推动企业进行安全整改的事件， 属于事件驱动中的经典事件。由于一般情况下重保都是由政府或者监管机构发起的，而且随着国家对于网络安全的重视，这些策略可以说是很痛的打在企业身上，能够极为有效的推动安全部门的落地工作。至于无论是事件驱动还是管理驱动，在我的认知里，沟通才是最为重要的。不要一开始就想着事件驱动，而是应该首先做好沟通。当沟通的结果不满足预期时，此时再进行事件驱动，本着外来的和尚会念经原则，利用外部提交过来的一些问题推动内部的发展。但是注意不要把自己放在研发、运维的对立面，而应该是互相协作。共同为客户提供好的安全保障。
第二点谈一谈重保实现的形式，重保往往是注重于形式化。有时候可能不切中实际落点。和企业安全防御的建设本身有些出入。但是并不意味着重保是无效的。同时往往也能暴露出一些问题。就是永远不要以战术上的勤奋，去掩盖战略上的懒惰。一群人，日日加班，在重保期间，24h online， 应急止血。这从另一方面只能说明了一件事，事前的企业安全架构没有做好，检测和止血的能力也没有自动化。同样仅仅依靠重保期间的高强度工作去应付检测时不起作用的。尤其是疲于奔命的应急和毫无预演和规范的止血操作。但是如果企业能够吸收重保带来的教训，能够在接下来的时间段内提高自身的安全建设，也是值得。总的来说，不能止于形式。
第三点谈一谈相反的一种情况，就是大促和重保。大促时候的重保往往和监管的等保，政府的护网不同。大促是企业本身做出的关于营销方面的重大决定。无论是确保风控本身，还是企业安全本身。在大促期间的保障行为毫无疑问是极为重要的。但是针对大型的互联网公司，大促可能带来超大流量，不亚于一次超大型的DDOS，虽然此时有些防护是在ISP和CDN上做了清洗，同时也通过人机验证过滤掉了一批用户。但是此时的流量和用户依旧是巨大的。同时无论是反爬还是安全设备也往往在此时会进行降级，比如不再全量检测，规则也进行降级。只保留核心的waf规则等等，避免把串联在边界的安全设备打垮，同时由于业务请求量的激增，也会导致日志收集系统流量暴涨。为了避免相关联的系统崩溃，有时也会关闭日志。尽可能的把资源全部留在业务上。那么这个时候怎么办？老虎打盹的时候需要依赖边界栅栏，边界的硬抗加硬件分光，大数据的检测平台，即便常用的日志收集出现问题，也要尽可能的保障在边界的检测行为。根据大促的特点，不会是全时段的，可以针对大促的不同时段，调整对应的规则，进行降级等等。另外还有很重要的一点就是提前做好演练。不要降级降挂了，在真正实操的时候出现了暗坑。此时业务当先，一切都将措手不及。还想到一件事，事件的统一收口： “核按钮”。 以及风险的统一收口：各种降级开关。