├── Facebook.md ├── README.md └── Server_security_operation.md /Facebook.md: -------------------------------------------------------------------------------- 1 | ## Facebook 故障 2 | 3 | - 2008-09-23 美社交网站Facebook周一"罢工" 部分用户无法登录[美社交网站Facebook周一罢工文章链接](http://www.chinanews.com/it/hlwxw/news/2008/09-23/1390493.shtml),[Facebook周一“罢工” 部分用户无法登录链接](https://news.pconline.com.cn/itnews/nw/0809/1427105.html) 4 | - 2009-10-13Facebook发言人布兰迪·巴克尔(Brandee Barker)周一称，近一周来数千个无法正常访问的用户账户中，已有部分恢复正常，但与用户个人资料和近期更新相关的数据可能已经丢失。自10月3日以来，Facebook访问个人资料以及登录页面时，出现了“正在维护，暂停访问”的提示。Facebook表示，这是“由于一个数据库出现了技术问题”，并强调称，这并非是受到黑客攻击或者其它恶意行为的影响。该网站称，按照正常处理流程，个人资料数据应该在第二天恢复正常。[Facebook近15万用户账户故障链接](http://www.ccidcom.com/hulianwang/20091013/5es86MLknXNxN9Fo.html) 5 | - 2010-02-22 Facebook出现访问故障 独立服务器出问题，[Facebook出现访问故障文章链接](https://tech.china.com/zh_cn/news/net/international/11066128/20100222/15823326.html)Facebook发言人马特·希克斯（Matt Hicks）表示，由于一台独立服务器出了问题，用户无法访问Facebook、查看好友档案或使用网站特殊功能，但受这次故障影响的只是“一小部分用户”。星期六晚上6点，Facebook表示问题已经解决，用户可以放心使用。 6 | - 2010-09-25Facebook称数据库软件问题导致严重故障，北京时间9月25日消息，据国外媒体报道，Facebook软件工程主管罗伯特·约翰森（Robert Johnson）表示，Facebook周四出现的故障是由于数据库软件问题而导致的。约翰森在博客中表示，此次故障是由于软件问题引起的，这款软件旨在检测和修复缓存中的错误。他写道：“导致此次故障的关键原因在于针对错误环境的一次不当操作。一款旨在检测缓存中无效配置值的自动化系统软件导致了此次故障。”[Facebook称数据库软件问题导致严重故障链接](https://tech.qq.com/a/20100925/000005.htm) 7 | - 2012-07-02Facebook再次发生故障：用户通讯录被篡改,继电子邮箱被更改后，Facebook用户的地址簿和电子邮件信息也出现问题。Facebook用户上周发现，他们在“时间线”中列出的电子邮箱被系统改成了@Facebook.com的邮箱，但却没有收到任何通知。随后便有大量用户通过Facebook和Twitter表达了不满。[Facebook再次发生故障：用户通讯录被篡改链接](https://aqzt.com/bubble/12245.html) 8 | - 2013-06-24Facebook称受漏洞影响六百万用户信息被泄露,Facebook发布了一个由于技术故障而导致的安全缺陷的警告，称他们可能泄露了六百多万用户的邮件地址和电话号码。“我们最近从我们的白帽小组获知了一个安全缺陷，能够使某用户获得与其有关联的用户的所有通讯信息。”Facebook在他们的公告中这样说道。[Facebook称受漏洞影响六百万用户信息被泄露链接](https://netsecurity.51cto.com/art/201306/400240.htm) 9 | - 2013-10-21Facebook維護出錯，故障逾2小時,Facebook在台灣時間昨天晚上8點多開始出現故障，造成某些服務無法使用，Facebook隨後回應是因維護出現問題，在晚上11點時已恢復正常。昨天晚上的Facebook仍然可以登入、瀏覽，但按讚、更新狀態或留言時都會出現錯誤訊息，該情況影響了全球的Facebook用戶，但不確定受影響的區域或用戶數量。[Facebook維護出錯，故障逾2小時链接](https://ithome.com.tw/news/83286) 10 | - 2014-4-27消息，周日，Facebook出现大规模宕机，受影响用户范围覆盖全球。据Facebook用户表示，当进入Facebook网站时，除了用户本人图像外，动态消息页面无法显示任何内容。众多移动端用户也表示，在自己的动态消息中，除了一些老旧的缓存内容外，没有任何消息。对于此次宕机，Facebook表示，“一些用户无法看到他们的动态信息，我们对此感到抱歉。该问题现已修复。”[Facebook被曝出技术故障 动态消息无内容显示链接](https://tech.qq.com/a/20140428/001805.htm) 11 | - 2014-6-19下午4点Facebook发生大规模宕机，电脑无法连上Facebook网站，手机、平板等移动设备的Facebook App也无法连线，Facebook的Messenger即时通讯也无法使用，几乎波及所有服务。此次Facebook宕机几乎是波及所有的服务，所幸灾情影响时间短暂。Facebook的服务在下午4点25分左右陆续恢复正常。 [1] 期间，全球多个国家受到影响，宕机持续了约40分钟。[6·19Facebook大规模宕机事件链接](https://baike.baidu.com/item/6%C2%B719Facebook%E5%A4%A7%E8%A7%84%E6%A8%A1%E5%AE%95%E6%9C%BA%E4%BA%8B%E4%BB%B6) 12 | 13 | - 2015-01-28 Facebook 瘫痪故障1小时,黑客组织发表声明称对故障负责，但却遭到了Facebook官方否认。今天 下午从格林尼治时间1月27日6：00(北京时间1月27日14:00)开始，登陆Facebook发生故障，页面显示：“对不起，出故障了， 目前正在抢修，会尽快修复。”[黑客抢着对 Facebook 瘫痪负责 遭官方无视链接](https://www.oschina.net/news/59178/hacker-response-to-facebook-fault) 14 | 15 | - 2017-05-9Facebook 的服务器今早宕机了，故障持续40分钟,全球最大社交网站 Facebook 一度发生故障，新加坡、马来西亚、泰国、日本、澳大利亚等地的部分用户无法浏览网站。[2017年5月9日]Facebook 的服务器今早宕机了，故障持续40分钟插图有用户在尝试登入时，网站出现错误讯息表示：「对不起，出现了问题。我们将尽快修复。」的提示语。Facebook 移动端 App 也有同样的问题。[Facebook 的服务器今早宕机了，故障持续40分钟链接](http://www.yunweipai.com/16188.html) 16 | 17 | - 2018年09月04日Facebook出现故障：部分用户无法发消息 问题已解决,Facebook本周一宣称，因为出现技术故障，一些用户无法访问Facebook并发帖，Whatsapp和Instagram也出现同样的问题，但现在问题已经基本上得到解决。Facebook新闻发言人解释说：“今天早些时候，因为出现网络问题，一些用户无法访问Facebook服务，或者在服务上发布内容。我们迅速展开调查，尽快恢复访问。现在问题基本上已经得到解决，每个人都可以访问并发布内容。给大家带来不便，我们感到抱歉。”对于多数受影响用户来说，本次故障持续时间不到90分钟，而且问题并非发生在特定地区。[Facebook出现故障：部分用户无法发消息 问题已解决链接](https://tech.sina.com.cn/i/2018-09-04/doc-ihiqtcan7883444.shtml) 18 | - 2018-11-19Facebook旗下的即时通讯软件Facebook Messenger周一在许多国家出现了无法正常使用的情况。 "Facebook Messenger软件在美国东部时间14:57时开始出现故障。" 这一时常状况尤其在波兰、英国和法国三国最为严重。 此外，葡萄牙、意大利、希腊、罗马尼亚、匈牙利、荷兰、比利时、丹麦、瑞士、挪威等国的居民也无法正常使用该软件的通讯功能。 19 | 20 | - 2019-03-13Facebook(FB)于当地时间早上出现故障，问题终于在14日早上得到了解决。 美国Facebook出现故障，投诉量目前最高上升至750万件，Facebook周四2019-03-14宣布，其全球大规模宕机故障现已基本恢复，但仍有可能经历间歇性的故障。对于故障的原因，Facebook的解释是，他们对服务器配置做了一些改变，引发了一连串的登录问题。 Facebook的此次大规模宕机发生在周三，波及范围包括了Facebook网站、Instagram和WhatsApp等，这也是Facebook创立15年来最严重的一次故障。[Facebook总算恢复正常了链接](http://www.it-times.com.cn/a/hulianwang/2019/0314/26641.html) 21 | - 2019-04-14美国社交网站Facebook大面积故障，“社恐人士”如临世界末日，这起令全世界惊恐的事件发生在美国时间的周日早上6：30（即北京时间的昨天晚上），从美国到欧洲再到亚洲，很多人都陆续发现他们“赖以生存”的社交网站Facebook，Instagram全都上不去了，而给朋友乃至公司领导发信息用的Whatsapp也完全发不出去和接收不到任何信息……[美国社交网站Facebook大面积故障，“社恐人士”如临世界末日链接](https://www.sohu.com/a/308196620_631340) 22 | 23 | - 2020-12-10Facebook Messenger出现故障！讯息卡住传不出去，无法显示已经传送！许多用户都回报表示 Messenger 讯息无法传送，私讯传不出去的状况。目前状况为时好时坏，世界多个地区都有 Messenger 无法发送讯息的状况发生。 24 | - 2020-12-11Facebook系统出故障 用户纷纷被死亡，美国社交媒体脸书闹出乌龙，大约200万用户“被死亡”，连这家网站创始人、首席执行官马克·扎克伯格也未能幸免。 25 | 26 | - 2021-10-04上午 11 点 39 分左右，美国社交媒体 Facebook、Instagram 和即时通讯软件 WhatsApp 出现大规模宕机，此次宕机长达近 7 个小时，刷新了 Facebook 自 2008 年以来的最长宕机时长。 27 | - 2021-10-08周五Facebook公司就其服务中断两小时向用户道歉，并将本周第二次全球故障归咎于另一个错误的配置更改。 28 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 服务器安全运维规范（Server security operation） 2 | 3 | 4 | ## 项目简介 5 | - 项目主要是汇集整理服务器安全运维规范，包括运维工程师必须遵守的规范、服务器运维中注意事项、故障避免手段等文档，帮助运维工程师避免服务器安全和运维故障，方便运维工程师学习成长。 6 | 7 | 推荐阅读： 8 | 9 | **项目**（点击预览）| **文章作者 ID** | **文章链接** |**学习资源** 10 | -------------- | ---- | -------- | ---- | 11 | [**# 安全运维规范 #**](https://github.com/aqzt/sso/blob/master/Server_security_operation.md)|[@ppabc](https://github.com/ppabc/)｜安全运维规范发起人 |[原创链接](https://github.com/aqzt/sso/blob/master/Server_security_operation.md)|[推荐](https://github.com/aqzt/sso)｜归档 12 | |[- 内部漏扫工具-巡风](https://github.com/ysrc/xunfeng)|[@ysrc](https://github.com/ysrc)｜同程安全应急响应中心|[原创链接](http://www.freebuf.com/articles/security-management/126254.html)|[推荐](https://github.com/ysrc)｜归档 13 | |[- Docker的蜜罐系统](https://github.com/atiger77/Dionaea)|[@atiger77](https://github.com/atiger77)｜atiger77|[原创链接](http://www.freebuf.com/articles/security-management/126254.html)|[推荐](https://github.com/ysrc)｜归档 14 | |[- jumpserver跳板机](https://github.com/jumpserver/jumpserver)|[@jumpserver](https://github.com/jumpserver)｜jumpserver|[原创链接](https://github.com/jumpserver)|[推荐](https://github.com/jumpserver)｜归档 15 | |[- 脚本自动安全检查基线](https://github.com/ppabc/security_check/tree/master/checklinux2.0)|[@ppabc](https://github.com/ppabc)｜安全运维规范发起人|[转载链接](http://www.freebuf.com/sectool/123094.html)|[推荐](https://github.com/ppabc/security_check)｜归档 16 | |[- 服务器安全事件应急响应排查](https://aqzt.com/1313.html)|[@ppabc](https://github.com/ppabc)｜安全运维规范发起人|[转载链接](https://aqzt.com/1313.html)|[推荐](https://aqzt.com/1313.html)｜归档 17 | |[- GitLab误删除数据库事件的几点思考](http://mt.sohu.com/20170203/n479805598.shtml)|[@左耳朵耗子](http://weibo.com/haoel)｜程序员，酷壳博主|[转载链接](http://mt.sohu.com/20170203/n479805598.shtml)|[推荐](http://mt.sohu.com/20170203/n479805598.shtml)｜归档 18 | |[- Gitlab从删库到恢复：丢失6小时生产数据](http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=2651663996&idx=1&sn=7c1eb9a34993ea50a943c73caa8bf4cb&chksm=8bcbedd5bcbc64c34f506c843d56180c65a64d36c1d9f5361d5f0e8445f8ebff57ff94db82da&scene=21#wechat_redirect)|龙井、萧田国|[转载链接](http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=2651663996&idx=1&sn=7c1eb9a34993ea50a943c73caa8bf4cb&chksm=8bcbedd5bcbc64c34f506c843d56180c65a64d36c1d9f5361d5f0e8445f8ebff57ff94db82da&scene=21#wechat_redirect)|[推荐](http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=2651663996&idx=1&sn=7c1eb9a34993ea50a943c73caa8bf4cb&chksm=8bcbedd5bcbc64c34f506c843d56180c65a64d36c1d9f5361d5f0e8445f8ebff57ff94db82da&scene=21#wechat_redirect)｜归档 19 | |[- 运维三十六计](http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=2651663842&idx=1&sn=faab6acb4bd87a1f1cfe6eb8d3dc5dec&chksm=8bcbee4bbcbc675db19a57aae5eb5307f91f2656bcb39be0e98fc132be22fd5813a84855f6ed&scene=21#wechat_redirect)|梁定安、周小军|[转载链接](http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=2651663842&idx=1&sn=faab6acb4bd87a1f1cfe6eb8d3dc5dec&chksm=8bcbee4bbcbc675db19a57aae5eb5307f91f2656bcb39be0e98fc132be22fd5813a84855f6ed&scene=21#wechat_redirect)|[推荐](http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=2651663842&idx=1&sn=faab6acb4bd87a1f1cfe6eb8d3dc5dec&chksm=8bcbee4bbcbc675db19a57aae5eb5307f91f2656bcb39be0e98fc132be22fd5813a84855f6ed&scene=21#wechat_redirect)｜归档 20 | |[- 围绕故障管理谈SRE体系建设](https://mp.weixin.qq.com/s?src=11×tamp=1634114776&ver=3371&signature=dAoNNqVMljmmAumw8KDyLdHtYdAofhUk-jBgx2IOUzX26RCYzkWfuykS4ElFnMIaywuu5Eb79d3mCLsWBv9AU5lXaB97cV1Y*wFozYhyErtz0-4*fRCkM6XV-mk9L9n2&new=1)|石鹏|[转载链接](https://mp.weixin.qq.com/s?src=11×tamp=1634114776&ver=3371&signature=dAoNNqVMljmmAumw8KDyLdHtYdAofhUk-jBgx2IOUzX26RCYzkWfuykS4ElFnMIaywuu5Eb79d3mCLsWBv9AU5lXaB97cV1Y*wFozYhyErtz0-4*fRCkM6XV-mk9L9n2&new=1)|[推荐](https://mp.weixin.qq.com/s?src=11×tamp=1634114776&ver=3371&signature=dAoNNqVMljmmAumw8KDyLdHtYdAofhUk-jBgx2IOUzX26RCYzkWfuykS4ElFnMIaywuu5Eb79d3mCLsWBv9AU5lXaB97cV1Y*wFozYhyErtz0-4*fRCkM6XV-mk9L9n2&new=1)｜归档 21 | |[- Gitlab管理员权限安全思考](https://aqzt.com/12170.html)|[@ppabc](https://github.com/ppabc/)｜安全运维规范发起人 |[原创链接](https://aqzt.com/12170.html)|[推荐](https://aqzt.com/12170.html)｜归档 22 | |[- OpenSSH-8.6p1离线升级修复安全漏洞](https://aqzt.com/12181.html)|[@ppabc](https://github.com/ppabc/)｜安全运维规范发起人 |[原创链接](https://aqzt.com/12181.html)|[推荐](https://aqzt.com/12181.html)｜归档 23 | |[- Facebook故障梳理](https://github.com/aqzt/sso/blob/master/Facebook.md)|[@ppabc](https://github.com/ppabc/)｜安全运维规范发起人 |[原创链接](https://github.com/aqzt/sso/blob/master/Facebook.md)|[推荐](https://github.com/aqzt/sso)｜归档 24 | |[- 职场中的那些话那些事](https://aqzt.com/12194.html)|[@ppabc](https://github.com/ppabc/)｜安全运维规范发起人 |[原创链接](https://aqzt.com/12194.html)|[推荐](https://aqzt.com/12194.html)｜归档 25 | 26 | 27 | ### 现状 28 | 目前，网上运维工程师服务器安全意识参差不齐，大部分都存在这三方面的问题： 29 | - 服务器安全不是很懂； 30 | - 服务器安全重要，但没按要求做，或安全设置不全面； 31 | - 服务器安全重要，安全设置都有做，但实际操作有遗忘，安全意识不强。 32 | 33 | - 比如：在2017/01/31 18:00 UTC国外Gitlab出现故障，丢失了6小时的生产数据！Gitlab 数据库终于在北京时间 2月2日 0:14 恢复成功（18:14 UTC 02/01）。运维工程师操作时。没有检查正在操作的服务器，以至于误删除了正常的数据。 34 | - [GitLab故障文章链接](https://www.oschina.net/news/81560/gitlab-707-users-lost-data) 35 | 36 | ## 服务器安全那些要做，那些不要做 37 | - 安全设置要不要做？做安全还是不做安全？还是说只做一些基础设置。 38 | - 如果安全相关工作，能让服务器和服务器集群更安全，那就要去做。 39 | - 安全的相关工作尽量做，不会做的想办法做，实在没法做的，那就延后再说，也许现在没办法做，可能以后有办法，想做总能找到办法。 40 | - 安全无小事，要想想不安全的后果，如果出现安全事件，数据泄露，数据库被拖库，后果是很严重的，这样的案例互联网上很多，就不多说了。 41 | 42 | - 项目的口号是：使用服务器安全运维规范，不掉坑，不背锅！ 43 | 44 | ## 一起来参与，补充服务器安全运维规范 45 | - 如果想要贡献或是交流的话，请加 QQ 群： 7652650 （安全运维） 46 | - Email：ppabc@qq.com 47 | 48 | 49 | ## 适合的职业 50 | - 运维工程师 51 | - 运维经理 52 | - 运维总监 53 | - 资深运维工程师 54 | - 安全运维工程师 55 | - 运维开发工程师 56 | - 安全工程师 57 | 58 | 59 | ## 说明 60 | ### 关于重要程度标签 61 | - 重要程度：R1-R5, 对应关系：基础(R1)、简单(R2)、一般(R3)、重要(R4)、非常重要(R5) 62 | - 建议：R3以上，运维工程师必须做到！做到的好处是：可以避免一些业务故障和安全事件！ 63 | 64 | 65 | ## 项目进度 66 | - 2017年2月2日，正式起草。 67 | - 2017年2月8日，第一个版本。 68 | 69 | ## 鸣谢 70 | 71 | -------------------------------------------------------------------------------- /Server_security_operation.md: -------------------------------------------------------------------------------- 1 | # 服务器安全运维规范---安全运维的事前、事中、事后 2 | 3 | 4 | # 事前检查和监控 5 | ## 提前检查 6 | - 1. 服务器和网站漏洞检测，对Web漏洞、弱口令、潜在的恶意行为、违法信息等进行定期扫描。 7 | - 2. 代码的定期检查，安全检查，漏洞检查。 8 | - 3. 服务器安全加固，安全基线设置，安全基线检查。 9 | - 4. 数据库执行的命令，添加字段、加索引等，必须是经过测试检查的命令，才能在正式环境运行。 10 | - 5. 建设SRE体系，比如：日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等等。 11 | - 6. 检查服务，线上重要服务避免单点问题，服务架构采用高可用方案。 12 | 13 | 14 | ## 数据备份 15 | - 1. 服务器数据备份，包括网站程序文件备份，数据库文件备份、配置文件备份，如有资源最好每小时备份和异地备份。 16 | - 2. 建立五重备份机制：常规备份、自动同步、LVM快照、Azure备份、S3备份。 17 | - 3. 定期检查备份文件是否可用，避免出故障后，备份数据不可用。 18 | - 4. 重要数据多重加密算法加密处理。 19 | - 5. 程序文件版本控制，测试，发布，故障回滚。 20 | 21 | 22 | ## 安全监控 23 | - 1. nagios监控服务器常规状态CPU负载、内存、磁盘、流量，超过阈值告警。 24 | - 2. zabbix或cacti监控服务器常规状态CPU负载、内存、磁盘、流量等状态，可以显示历史曲线，方便排查问题。 25 | - 3. 监控服务器SSH登录记录、iptables状态、进程状态，有异常记录告警。 26 | - 4. 监控网站WEB日志（包括nginx日志php日志等），可以采用EKL来收集管理，有异常日志告警。 27 | - 5. 运维人员都要接收告警邮件和短信，至少所负责的业务告警邮件和短信必须接收，运维经理接收重要业务告警邮件和短信。（除非是专职运维开发） 28 | - 6. 除服务器内部监控外，最好使用第三方监控，从外部监控业务是否正常（监控URL、端口等），比如：监控宝。 29 | - 7. 采用k8s集群管理，容器监控，对项目POD使用CPU和内存排序，监控超过一定阈值告警，比如单个服务超过4G内存告警，可以发现服务内存溢出等问题。 30 | 31 | 32 | ## 故障避免预防 33 | - 1. 网站WEB增加WAF，避免XSS跨站脚本、SQL注入、网页挂马等漏洞威胁。 34 | - 2. 程序代码连接数据库、memcache、redis等，可以使用域名（域名HOSTS指定IP），当出问题，有备用的服务器，就可以通过修改DNS或者HOSTS，恢复服务。 35 | - 3. 建立应急预案机制，定期演练事故场景，估算修复时间。 36 | - 4. 部署蜜罐系统，防范企业和服务器内网APT攻击。 37 | - 5. 建立双活集群，包括业务服务的高可用，避免业务服务单点。 38 | - 6. 服务器集群采用跳板机或堡垒机登录，避免服务器集群每台服务器可以远程连接管理。 39 | - 7. 操作重要业务升级、迁移、扩容……之前，列一下操作步骤，越详细越好，实际操作按步骤操作，操作完做好记录。 40 | - 8. 测试环境，预发环境，线上生产环境，要做好环境隔离，避免测试环境使用生产环境数据库缓存等资源。 41 | - 9. 测试环境，预发环境要避免外部访问，做好IP限制和防火墙策略。 42 | - 10. 服务器集群私有DNS服务，需备份DNS日志，方便审计，可以避免和发现类似Py仓库request恶意包投毒安全问题。 43 | - 11. 集群服务程序需考虑无状态业务，可支持扩容缩容，熔断，降级方案，方案的合理性需开发和运维一起评估，方案需开发和运维都认可，并验证演练过。 44 | 45 | 46 | # 事中操作 47 | - 1. 网站WEB增加WAF，发现XSS、SQL注入、网页挂马等攻击，会自动拦截，并记录日志。 48 | - 2. 检查服务器数据备份是否可用。 49 | - 3. 在处理需求和故障时，执行风险命令（比如rm、restart、reboot等）需再三确认，执行命令前，检查所在服务器，所在服务器路径，再执行！ 50 | - 4. 不要疲劳驾驶，喝酒不上机，上机不喝酒，尤其别动数据库，避免在不清醒的状态下，在服务器上执行了错误命令，导致数据丢失或业务故障。 51 | - 5. 在处理事故时，一定要考虑处理措施是否会引发连锁故障，重要操作三思而行。 52 | 53 | 54 | # 事后检查分析 55 | - 1. 实现网络安全可视化管理，可以看到每天有那些异常IP和异常URL请求，服务器集群开放端口列表等。 56 | - 2. 能对全网进行安全策略集中管理。 57 | - 3. 统一日志收集和分析。 58 | - 4. 备份及篡改恢复功能，程序文件、图片、数据文件、配置文件的备份，故障回滚机制。 59 | - 5. 对攻击日志进行深度分析，展现攻击路径、攻击源，协助管理员溯源。 60 | - 6. 践行DevOps的无指责文化，尤其是在做事故分析时。事故分析重在定位原因，制定改进措施； 61 | 62 | 63 | # 事后故障定级定责 64 | - 1. 故障告警是否及时，告警是否周知相关人，运维处理是否有及时，运维不能处理是否有及时通知开发人员介入； 65 | - 2. 故障点，事前是否有应对方案，方案是否能完全解决故障，方案是否合理，方案是否开发和运维都认可，并验证演练过； 66 | - 3. 故障应对方案，如果合理，运维没按流程要求操作，运维次要责任； 67 | - 4. 故障点是否运维人员直接或间接导致故障，如果是运维操作直接导致，运维主要责任，间接导致运维次要责任； 68 | - 5. 操作人员是否存在主观故意，承担主要责任； 69 | - 6. 故障定级定责可根据业务情况，设置红线，比如：明知可能会导致故障，还操作，未验证的配置，直接操作等等； 70 | - 7. 故障定级定责可以参考《SRE:Google运维解密》书中介绍的方式； 71 | - 8. 故障报告里面需包含，告警时间，运维上线时间，运维开始处理和定位问题时间，服务恢复时间，服务全部恢复时间，验证时间，故障影响面，SLA，故障处理中遇到的问题，耗时部分，故障避免方案； 72 | --------------------------------------------------------------------------------