携程宕机12个小时后的技术反思, 内行看门道

想必大家对前几天携程跟艺龙合体这件事还记忆犹新,现在蜜月还没度完,剧情直接180度反转了!!!

《携程今早被攻击 网站服务及App全面瘫痪》
《携程网遭攻击全面瘫痪网传数据库被物理删除》
《携程瘫痪疑遭离职员工报复 官方否认数据丢失》
… …

更多新闻就不一一赘述,估计携程现在已经忙的没工夫提裤子了。。。。。

咱都是搞开发的,各种小道消息开始在群里传了,众说纷纭,看过以后真心感到担忧。

携程事件无论结果如何都给咱们提了个醒:“如何保证数据安全?”

希望就携程这件事大家各抒己见:

1、大胆的猜测一下事件发生的原因?
2、如何应对“内黑”/“攻击”?
3、为何数据备份没有起到作用?
4、怎样避免公司重蹈携程覆辙?
5、等等……

1

事故根本问题是服务依赖和启动依赖管理没做好,使得局部问题扩大化了。从携程最后的解释来看,他们的后端是典型的微服务架构,但是恢复时间这么久,也就是没意识到微服务会带来依赖管理的隐患,自己把自己坑进去了

内部服务部署的依赖管理是没有足够智能和自动化,掺入了不少手工操作的工作

微服务架构实践上的失误。如果使用了Docker这样的容器,在后期恢复服务时候能够获得不少部署速度上的提升,也许可以减少恢复所需的时间。但并不能从根本上杜绝这种问题的发生。Docker在集群化部署的实践里面会比较强调依赖管理自动化,比如Compose就是做这个的。但也不是所有Docker集群工具都有,比如Kubernetes就不包含服务依赖的管理

 

2

解决做法是从黑盒运维(运维人员不断的去做重复性的操作,不知道应用的依赖关系,哪些配置是有效配置、哪些是无效配置)走向白盒运维

3

DO分离,权限分级,重大变更的确认,统一的应用管理,灰度等等。灰度是最重要的变更策略,都不遵守。 必须把制度和流程固化 到产品中,把变更灰度作为工具的一部分,实现平台约束

对信息安全要重视

服务器双机备份,异地双机房备份,切记所有服务器交由一个人管理,并且权限尽量最小化。

权限+多人共同认证。
首先权限要达到,其次要多个人一起认证才能打开操作。

对员工好点,保持公平, 再安全的系统也能从内部攻克,再完善的流程也需要人执行,人有钱了就怕失去,这是人性层面的事情,只靠技术和管理手段是不够的

 

其它:

公关反应速度慢

部分参考
没有十全十美的技术!携程事件之后,技术专家们的建议与反思-CSDN.NET
http://www.csdn.net/article/2015-05-28/2824803

发表评论

电子邮件地址不会被公开。