这是一个思考了很久的题目，至今我自己没有标准答案。
“评价“是工作里无法回避的一个动作，虽然它字面意思上带有居高临下的审视意味，但人往往也无法回避自我评价。尤其是，当职业生涯发展到中后期，随着职级的升高，你的上级注定了无法在专业领域里超越你，上级对高P有一个潜在的期待，就是“你最好告诉我，我应当如何评价你工作的好坏，而且，要让外行的我，听起来符合逻辑”。
无法做好这件事情的高P注定了不会舒服，至少无法获得期望的信任、资源，以至于无法开展自己认为正确的工作，继而导致工作效果不佳，背锅黯然神伤。
所以，这几年我一直拷问自己这个问题。
当我只负责一个小厂的大部分安全职能时，我觉得自己没有过多的被这个问题困扰过，因为人足够少，以至于出任何问题都可以用“安全不是绝对的”来搪塞过去，安全做不到绝对的100分，是当时的万能回答。
当我负责一个大厂的垂直职能时，我也没有太被这个问题困扰。因为我的上级大概的会给我定一个通俗易懂的目标。比如反入侵，要求真实发现率 xx%以上。
我曾设身处地的幻想过，如果我当时承接了隔壁团队，比如SDL团队，当时他们的目标也比较简单，在公司业务高速发展的时候，漏洞的绝对量是否能持续稳定的控制住。是否在类似乌云的平台上，对比得出我们比同体量的公司问题更少（对应的资源差不多）。
但是，当我负责整体的基础安全（传统安全）后，我突然发现，这个回答变难了。
于是，在刚刚入职后没多久的半年汇报上，我遇到了这个问题，CTO问我，你给自己打多少分？
我认真的评估了一下当时的状态，百废待举，一切刚刚起步，虽然有阶段性的进展，但是距离心目中“能够做到”的目标，还是很远。
于是，我回答，按照建设效率和质量看，80分以上，但是按照实际的风险控制能力，自认为还不及格。
事后，我得到了上级的指导：好不好，不光要看实际的风险控制能力如何，也要看跟谁比。
恍然大悟，但为时已晚。
有时候，面对公司高层的交流机会并不多，印象分一旦错过了，就很难再找机会弥补。
所以今天，我尝试着把这段时间的思考，做个简单的记录
先说结论：安全工作的好坏，在于认知的准确性和投入的合理性以及执行效果的综合评估。既要跟公司的实际情况相结合，也要横向做业界对标，才有意义。
- 认知的准确性
- 投入的合理性
- 执行效果
- 业界对标
1. 认知的准确性
安全工作是没有绝对100%的，这句老生常谈成为了很多“明明可以做好，但是没有做好”的劣质工作的挡箭牌。
四哥有一句经典的话，在安全圈老一辈从业者里非常流行，叫做“你真的尽力了么？”，尽力与否，并不完全取决于个人是否卖力。曾经有一个鸡汤段子，是说小男孩被要求去处理一块明显超过自己能力范围的石头，而大人说，他还没有尽力，因为至少小男孩没有去求助大人。
比如说，在公司安全漏洞的处置上，经常有人说我一开扫描器，业务就闹，弄出事了，不让我扫，所以我就不敢扫。然而公司出了漏洞，明明扫描器就能发现的，他们不让我扫，却怪我没用。所以我委屈，所以安全工作不好做。
这就是一个经典的“明明可以做好，但是却没有做好”的事情。
我刚加入现在的团队时，扫描器的安全运营同学就是这么跟我反馈的，所以扫描器研发成功之后，只在我入职前的2个月，做了1次国庆前的保障临时性扫描。事实上，如果对“变更管理”有一些了解，上述工作可以遵循变更流程，进行风险提示，变更知会，然后灰度进行，拉通业务改造监控逻辑，事情是可以进行得下去的。
最终，我们很快完成了“黑盒扫描器”例行化开启运营的工作，就像很多做的优秀的同行一样。最终让公司具备了对应的漏洞检测能力，并在SRC反馈新漏洞时，有了复盘的基础 —— 如果都没有例行运营起来，我们连复盘的资格都没有。
在很多其它的场景也类似：
比如，MS17-010补丁发布的时候，它的评级严重性微软说的很清楚，但是马上安排全公司最快速度应用补丁的团队并不多，他们在Wannacry肆虐之后，倒是喜欢宣传自己如何的紧急加班。既然紧急加班一个周末能干完的事情，4个多月的时间，之前干嘛去了？
再比如，主机agent在部署的时候，很容易造成资源占用过高、Bug导致宿主机崩溃，于是很多安全工程师写出来agent之后，在公司就没有100%的推广覆盖过。因为装不了多少台，一个事故就会让业务排斥抗拒拒绝部署，导致公司实际上根本不具备主机入侵检测能力。可是，既然知道这个事情是必然的结果，熔断降级自杀设计有没有，能不能让公司95%以上的机器具备对应的能力先？慢慢迭代收拾长尾的难题？
还比如，白盒审计工具扫出来一大堆的误报，以至于无法运营，那有没有想过只让误报低的规则运行起来，逐个的增加和优化规则，在低误报的前提下，提升白盒的能力？
这一切的一切，没经验的同学一上来往往会“畏难”，你说这事干的成，只是他当时干的方法不对，他还会觉得委屈。逼急了就会“妥协”的做一些费力可能还没什么效果的事，至少无法常态化运营下去的事，临时应付表示一下自己是听话和尽责的。
因此，我认为，评价安全工作好坏的第一条，其实对当事人“认知”能力要求最高，起码要知道这件事，是不是可以被干好的，要有一个客观的了解。
而这种“认知”能力除了自己探索学习，其实是有捷径可以走的。那就是行业对标。
在同一件事上，把国际、国内、同体量公司的当前状况摸一遍，多多少少会有合理的判断，当然，由于安全行业成熟度一般，所以有很多“其实可以做好”的事情，国内同行们并没有做好，导致误判，也是很常见的。
这个话题就按下不表了。
2. 投入的合理性
在有合理的认知的前提下，首先需要思考的是自己所负责领域的风险全景图，以及合理的应对节奏。
这里其实使用对标的方法也不难输出，难就难在，很多人会抱怨自己当前的资源，远远无法cover这么多事情。
因为资源不足，所以即便知道很多风险没解决，暂时也不去动它，这事不能怪自己，要怪，就怪领导不重视，不投入。
这观点其实也是有问题的。
对于公司高层，绝大多数时候，是认可公司资源是不足以支持你很舒服的做事情的。但是，这绝对不意味着，一件非做不可但事，公司也坚持不给资源。
不给资源的道理只有一个 —— 你没能有效的说清楚这件事，而这，并不是管理者的错。
打个不太恰当的比方，老板手里有100万，现在沙漠里，口渴了，旁边有个人拿着农夫山泉卖100块，你觉得很贵不划算，默认老板不会掏这笔钱，因此没给老板说有水卖。可是你咋知道老板不愿意掏这100块呢？
当然了，也的确有很多从业者会夸大其词，自己YY安全风险很大，可以造成的后果，比这个公司的市值、营业额还大得多，然后老板不予置评，不支持，觉得自己委屈的。其实多半是没有换位思考，假设自己是老板的partner，在众多经营风险之中，公司有限的资源，到底应当分配多少来应对这些事情。
说直白一点，如果你能处理的风险盘子很大，而公司没有到对应的阶段，我觉得最佳的策略可能是跳槽去一个更大更重视安全的公司，而不是在当前的公司里忽悠老板在安全领域投入过份的资源 —— 否则公司主营业务能不能发展起来还不知道，资源可能先消耗没了。
假设，资源的问题放在一旁，已经确定只有有限的资源了，面对风险大盘，如何看菜下饭合理分配，其实也很考验安全负责人的认知。
务实，但是不出彩的地方要投入，务虚，但是对于团队前瞻性或者知识结构储备的地方，同样值得投入。尤其是，当安全负责人本身视野有限时，花大量资源，但是用很低效率的方法去解决单个问题，以至于其它风险的投入不足，却误以为是高层不支持不投入的现象，也是很常见的。
举个例子，比如大多数公司会存在一个问题，就是权限管控，多数时候是不符合“最小化”的安全最佳实践的。因为权限分散在太多的系统里，运维权限、DB权限、应用系统权限（知识库、代码仓库、报表平台、HR系统……），公司规模越大，这些系统越多。
而这些权限问题往往很容易暴露给高层看到，总会出事，于是安全团队就必须迎难而上。
有些同学会非常努力的承担权限管理的职责，试图去帮公司的每一个系统，设计一个权限管理的清单，谁可以访问，谁不能访问。因为兹事体大，所以还会投入很多人力，很长时间去做这个项目，做到最后，各种访谈，各种调研，各种数据分析，判断谁应不应该访问哪一个权限。（这里还不算开发全局IAM权限管理系统的工作量）。公司越大，要做完这些工作的时间越长，而且可能还做不完……
一个很长的时间过后，内部红蓝对抗依然可以轻松的暴露问题，权限依然没有收敛到预期的目标。可是，本来就捉襟见肘的安全团队，的的确确投入了很多精力在这个项目上，以至于还有很多其它同样重要的风险，没有办法开展治理工作。
这时候，与其怪公司不给足够的HC，不如考虑一下，是不是工作的方法可以有优化的空间。如果把权限治理的工作下放到每一个系统的负责人，他们自己完成对应的工作，就是发动了群众战争，把大量的工作分摊到了每一个人的头上，你只需要集中精力做抽查、答疑解惑、标准制定，可能很快就能做到更好的效果，还节约了大量安全工程师。
因此，争取合理资源、在有限资源的前提下，合理安排风险治理的投入，也是一个极大的难题。希望不要等安全case发生了，复盘的时候才发现，这是一个业内已知，早就在视野范围内，投入资源能解决却被耽误了的事。
3. 执行效果
当我们有了正确的行业认知，知道什么事情可以做好，也做了合理的资源分配，确保了应该要做的事情，都有人去做了。
接下来要做的就是看执行的效果。
每一件事，投入一定的资源之后，多长时间，应该有什么样的产出，很多管理者其实拿不定主意。因为管理者无法、也不能亲力亲为的盯着每一个项目，而一线的执行者不一定都是拥有丰富经验、卓越见识、积极主动而且极富创意的人，他们的工作思路、工作技能，会限制他们的发挥。
有时候，你觉得这件事按照1，2，3的方法很快就能见效，可是一线执行者瞻前顾后，想了一个很完美的效果，第一个阶段调研探索就要花3个月，而你认为1，2，3做完也不过需要1个月。
执行的效果差距就会偏离预期很多了。
如何保证自己负责领域的多数事情有效执行，其实是一件非常困难的事情，尤其是，团队大了以后，很多领域甚至不是自己擅长的。所以，那个效果是真的偏差过大，还是自己异想天开乐观估计了，也很难判断。
这种时候，最重要的可能已经不是亲力亲为去参与每一个重要项目的评估。
抓主要矛盾，抓大放小，可以节约自己的注意力。
而找到每一个领域最胜任的人（在行业里，这个领域做得相对领先），有战斗力的合作伙伴，可能是更重要的事。
否则，就只好接受管理半径有限的客观规律，等待着负面反馈的到来，还很难解释自己已经尽力了 —— 因为出事的时候，去复盘，有时候多半是能发现这些事其实能做的更好，但是没有提前尽早关注到。
另外，的确很多事都可以做的更好，但是一线同学有自己的客观困难，比如他们负责的工作其实很广很杂，无法在这些事情上投入特别精细化的精力，以至于不得不妥协将就现在的工作质量。这里又涉及到资源分配合理性的交叉考验，完美主义并不是特别理想的管理模式。
4. 业界对标
其实上面说的3个事情，都适用于业界对标。
知乎有句名言“以绝大多数人努力程度之低，根本轮不到拼天赋”，我认为在安全领域里有一定程度的体现。因为大多数从业者其实是在没有“业界对标”的前提下自行摸索的。
因为绝大多数公司的安全投入远远不足以让大家对垂直精细化的运营效果作出承诺，所以，一定会存在很多“完美主义者”眼中可以做好，但却还没有做好的事。
此时，“理论上”可以做好的事，和事实上业界投入一定的资源，做到的程度，是有差距的。自己团队的输出，和业界对比，是否做到了同等资源，效果更好，或者更少资源，效果差不多，算是一个比较好的参照标准。
就目前而言，业界经常会创造新的概念、术语，
但是去掉那些花里胡哨的PR包装，安全领域这么些年对应的风险和解决思路，变化得并不多。
尤其是Google在基础设施安全里介绍自己如何解决各种各样的风险实践后，从BeyondCorp到BeyondProd，无一不是朴实无华的实打实的干货。不吹嘘各种高大上的名词概念，老老实实的把安全能力分层，在每一层打磨到极致。
可以说，Google提供了教科书般的理论指导，只是由于这家公司的技术过于领先，自研了太多的东西，依赖开源红利的东西太少，参考意义打了很大的折扣，所以我们其实可以多参考一下Amazon。这家公司可能提供了更多的最佳实践。
至于国内的其它Top大厂（或者包括国际上的很多大厂），多少是相似的概念，但是资源和工程化落地运营效果可能会有一些不同。
我们最大的差距可能是在了解大致逻辑之后，缺少对应的工程化资源，因此无法100%照搬。
但是取法乎上，得乎其中。见过很多同学在对标的时候，喜欢选择国内相对体量接近，但是其实不能代表最佳实践的做法，这样可能是取法乎中，得乎其下了。
目前绝大多数不参考借鉴最佳实践的“自主创新”，可能很容易导致一个错误的方向，二次返工的综合成本也许超过一次认真对标后的谋定而后动。
就跟安全届告诫 “不要自创算法”是一样的道理。
可能很多人会说，我倒是想对标，可是，这些公司的人我也不认识啊，他们也不肯说啊，我想，这可能就是另一个话题了。
全文，就这么仓促的结束吧，毕竟只是临时心血来潮的一家之言。