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

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

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

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

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

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

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

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

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

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

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

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

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

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