妄谈: 技术安全运营的未来是安全架构师

>> 资历尚浅，见识狭隘，仅以自身所见所闻所学，妄谈一下这个话题，当个乐子，随便看看。

问：“架构师”是岗位还是思想？

：在阿里对架构师的定义是“去应对复杂性，应对熵值不断增加的一个组织性的力量。”“软件/系统架构的核心挑战是快速增长的复杂性，越是大型系统，越需要简单性。”

    识别和控制复杂度正式“架构师”在对复杂核心系统设计时候要考虑的重点。

    而架构的基本出发点是效率，通过合理的架构设计、有序化重构，实现效率最大化。

    架构师不应该脱离业务上下文而单独存在，好的架构师是为解决复杂问题而存在的，思考如何能用抽象的方法解决一类问题。将发现的问题进行抽象和归纳，定义问题的基本要素，定义出问题的短期和长期解决方案，推动技术整体的进步。

    简化一下架构师本质上是一种“发现问题—定义问题—解决问题”的能力或是思考模式，而如何定义问题是“架构师”是否优秀的核心衡量。

问：“架构师”需要具备哪些能力？

：参考JD Model，“架构师”要具备的五个能力，1. 全局视角 2. 技术广度 3. 持续学习 4. 业务理解 5.结果落地。

    不同level的架构师的差别在于建设的范围，例如在阿里体系内，技术序列从P8开始就要具备架构师的能力，P8往往只负责一个单体业务，P9会负责一个更加复杂的单体业务，到了P10就要思考整个行业，而P11及以上就要跨行业、从集团整体角度去思考问题，最牛的架构师莫过于“1979年，那是一个春天，有一位老人，在中国的南海边，划了一个圈……”

    但是我更认可的是“架构师”是一个底层的人才特质，与层级无关。（实际上有大把P8并没有任何的“架构师”思维）

问：“架构师”需要非常精深的技术能力吗？

：如果身兼“架构师”的角色，往往就没有足够的时间去持续的精深技术，但是这个角色本身需要大量的实践和知识的积累，需要接触更多的人和事，用新的方法来解决新的问题。要具备这个能力，就要持续的保持先进技术学习的能力和经常性的实践。

问：“安全”“架构师”存在的意义是什么？

：在上一篇文章中写了“技术安全运营”，那么在这之后的发展我浅薄的认为应该就是“安全架构师”了。参考架构师的Job Model，作为架构师，应该具备横向和纵向两方面的职责。

    一方面不能脱离实际的业务上下文，要深入到业务中，从业务战略到技术战略再到安全战略，到设计、实施、再到治理。提供一个简单、清晰、优秀的设计。在安全风险治理中什么是好的设计呢？默认安全和可持续化是最核心的两点。

    就像在实际的工作中，很多风险治理都是靠人力去运营，稍有成色便在PPT上侃侃而谈大书特书，但是实际上只要项目转为日常化运营，那便等于没人运营了。要想做到低成本的可持续风险治理何其难。

    再者是默认安全，在各类风险中，人的因素不可谓不大，一味的用各种方式要求“人”来保证安全，终归事倍功半。

    “安全架构师”在这其中，既要能设计出有效的阶段治理策略，又要保证这样的设计可以迭代可持续化。

    另一方面，“安全架构师”要融入到“系统架构师”圈子中，与他们就重要的概念达成一致。因为不存在哪个业务先设计好架构然后去发展的，大多都是野蛮生长然后再规范化。那在这个过程中，一个优秀的健壮的安全的架构需要“架构师”们一起对重要的概念、原则有广泛的共识，例如“默认安全”。

    “安全架构师”必须是一个长期主义者，要长期的去看一些东西。而要具备“长期主义”，是需要有信仰的，信仰何来，需要持续的对前沿的理念、技术进行学习，同时对身处其中的业务足够的了解，更重要的是要有一个可以培养“长期主义”的土壤（虽然现在的浮躁对于长期主义并不友好）。

    还有一个重要的点，不论是“架构”还是其它的比如“云安全”等，一定不要狭义的去理解，就比如“云安全”，不仅仅包括“K8S”，也包括“云系统网络的设计”、“云上应用的设计”、“云上数据安全保护”等等，“架构”也是同理，技术、产品、业务、经营等等都要交叉去思考，才能有一个更全局的视角和思考，“安全”真的是小的不能再小的一个赛道了，跨圈看看会发现有大量优秀的设计可以借鉴回来。

看完这里，相信各位必然会有许多不同的见解，我也是正门外窥探，随便看看好了。

​

原文始发于微信公众号（电驭叛客）：妄谈: “技术安全运营”的未来是“安全架构师”