开发、安全和运营总感觉隔着墙，怎么才能真心一起顺畅合作呢

“开发、安全和运营总感觉隔着墙，怎么才能真心一起顺畅合作呢”这个问题，其实很多公司都在面对，说白了，就是写代码的、管安全的和维持系统运行的三拨人，各自有各自的目标和压力，互相不理解，甚至有时候会觉得对方在给自己“使绊子”，要打破这堵墙，关键不是搞一堆复杂的流程,而是要从根儿上改变大家的想法和相处方式。

得让大家的目标变成一样的，不能是开发只顾着赶紧把新功能做出来上线，安全只想着把所有的漏洞都堵上哪怕项目延期，运营只求系统四平八稳最好一点变化都没有，这种各自为战，目标打架，合作肯定顺畅不了，得有一个所有人都认同的更高目标，为用户提供既好用又安全稳定的服务”，在这个大目标下，大家就成了一个战壕的战友，开发在写代码的时候，如果能想到这个功能万一有漏洞被黑客利用了，最后半夜爬起来加班处理问题的其实是运营的兄弟，那他可能就会更主动地多检查一遍代码，安全团队如果明白过度严格的要求会让新功能晚上线一个月，导致公司错过市场机会，最终可能影响所有人的饭碗，那他们可能就会更愿意和开发一起商量，找到一个既满足安全底线又能快速上线的方案，说白了，就是让大家意识到“一荣俱荣，一损俱损”。（这个思路在很多谈论团队协作的文章中都有提及,核心是建立共同的目标和责任感）

沟通不能总在出问题的时候才进行，不能是代码写完了，丢给安全团队去扫描，扫出一堆高危漏洞，然后安全部门发一封措辞严厉的邮件给开发负责人，要求限期修复，这种时候，开发团队的感觉就像是考试不及格被老师训斥，自然会产生抵触情绪，同样，也不能是运营团队直到新版本半夜上线时，才发现这个版本和某个系统不兼容，导致服务瘫痪，然后怒气冲冲地打电话把开发从被窝里叫起来，这简直就成了“仇恨”的种子，正确的做法是，让大家很早就坐在一起，开发在构思新功能甚至写第一行代码之前，就应该邀请安全和运营的同事一起来开个简短的会，问问：“兄弟们，我这个想法，从安全角度看可能会有什么风险？从运营角度看，部署和监控起来方便吗？”这种早期沟通花不了多少时间，却能避免后面绝大部分的麻烦和返工，安全和运营的角色从一个“验收者”或“挑刺者”，变成了“共建者”和“顾问”，感觉就完全不一样了。（这种早期和持续沟通的理念,是敏捷开发和DevOps文化非常强调的一点）

工具和技术也能帮忙拆墙，如果能让一些流程自动化，减少人为的摩擦和等待，合作也会顺畅很多，建立一套自动化的流水线，开发人员代码一提交，就自动触发一系列安全检查、自动化测试和部署到测试环境的流程，安全规则和检查点就像交通信号灯一样内置在这个流程里，代码有问题会自动“亮红灯”并立刻通知开发者，而不是等到最后才由安全人员手动去发现和报告，这样，发现问题、反馈问题、修复问题的周期就变得非常短，而且是在开发流程中自然完成的，开发者会认为这是帮助自己写出更好代码的工具，而不是安全部门用来卡自己的关卡，同样，运营的监控工具也可以对开发透明，让开发人员也能实时看到自己写的功能在线上运行得怎么样，有没有出错，性能好不好，当他们亲眼看到因为自己的一个bug导致服务器报警频发，根本不用别人说，自己就会想着赶紧修复，工具用好了，就能把三拨人的工作自然而然地编织在一起。（自动化工具链是支撑DevOps实践落地的关键技术手段）

也是很重要的一点，就是人与人之间的理解和信任，公司可以多组织一些跨部门的交流活动，不一定是正式的会议，可能就是一起吃个午饭，或者搞个技术分享沙龙，让开发的同事讲讲他们最近在用哪些新技术，面临的业务压力是什么；让安全的同事分享几个真实的、惊心动魄的黑客攻击案例，让大家明白安全防线失守的严重后果；让运营的同事吐槽一下他们遇到过哪些“坑爹”的部署和最难排查的故障，当大家不只是邮件里的一个名字，而是能面对面交流、知道对方也是活生生的人、也有各自的难处和专业知识时，合作时的心态就会平和很多,会更愿意站在对方的角度想问题。

拆掉开发、安全和运营之间的墙，不是发一个行政命令就能解决的，它需要从共同目标、沟通方式、工具支持和文化建设这几个方面慢慢来，让大家逐渐意识到我们是一个团队，而不是三个部门，当大家都朝着同一个方向使劲，把对方的成功也看成是自己的成功时,这堵墙自然就不存在了。