0x01 前言

做工程师的以为做了专家就不搞运营了，做安全运营的以为做了架构不需要关注运营了。实际上运营又是始终逃不掉的一个话题，不过今年好在不像前两年吹的那么厉害了。简单总结下架构中的运营工作。

0x02 正文

先讲讲常规的运营工作有哪些，需求收集（安全团队内外的奇奇怪怪需求）和风险跟踪这两块是日常工作中最常见的，主要体现在架构评审和安全咨询两部分。拿架构评审举例，经常需要沟通去说服业务方接受一定的 baseline。但业务方往往会有以下的理由：

• 我们在内网，不需要密码，不需要 tls，key 就存数据库就行；

• 别人怎么怎么用的，别的公司都是这么用的；

• 这个 github 上的 star 分数很高；

• 这个业务很急，优先级很高；

在这种背景知识不对等的情况下，一方面由策略/规范去强制要求业务方遵守规则，另一方面需要一遍遍的耐心沟通，补齐背景知识。而往往结果又会变成：

• 一个文档十句话，架构图一个没有，上下文也不记录；

• 丢个第三方软件的链接当作答案，让你自己去看；

• 加密哈希编码傻傻分不清楚；

• 几个会开下来，该改的地方一个没改；

架构评审做的越多越让人感觉无奈。针对事后的风险管理，即便通过流程进行跟踪，但很大程度上会出现牛头不对马嘴的解决方案，会上说的是一套，实际做的又一套，甚至可能没往某方面设计就 close 掉风险点了。

除此之外还有规范建设，内部（或者和其他部门一起）写策略，写基线，写管理办法，写流程等等。一般格式会分为：目的，范围，内容，附录几块。初版之后要 review/cross-review 规范，release 规范，update 规范。这些规范应该具备统一的格式，编号，水印，固定的更新周期。同时由于有的是写给员工的，有的是写给 IT 的，还有的是写给运维的。还会涉及到能力推广，这又包括培训，宣讲，分享几种不同的情况，当然可能还需要建设一个团队对外的 Portal，供企业内其他部门的员工查看。一般会包含以下几个板块，org&leadership，mission，capability，event，policy&sop，所有在 portal 上的都将被认为是 released 版本。 草稿版本放在 wiki 上编辑。

0x03 总结

以前是在“砖家岗”做架构，现在是架构岗上做“砖家”。从 9 月来是平均每周 20h 的会议，10 月的几周更是爆炸，感觉最近至少要平均到 30h 了，有时候真的不知道是未来先来还是稻草先来。人特别累的时候脑子里就会疯狂嗡嗡嗡，思绪飘飞，有时候会把想到的写下来，可能会缓解一点，但有时候又没什么作用。想想很久没跑步了，今天去跑了一次，才 2km 就已经大汗淋漓，想来想去，还是休一天假，放过自己。毕竟狗命要紧。