《AWS历次事故分析及启示》读后感
#######################################################如有转载，请务必保留本文链接及版权信息
##欢迎广大运维同仁一起交流linux/unix网站运维技术!
##QQ:335623998
##E-mail:335623998@qq.com
##博客： http://dreamway.blog.运维网.com/
##weibo：http://weibo.com/zhaixiangpan
#####################################################
今天上午weibo上看到网易汪源的《AWS历次事故分析及启示》便有了此读后感，一点个人拙见，还请大家拍砖。
《AWS历次事故分析及启示》摘要
https://s1.运维网.com/attachment/201303/154318511.jpg
https://s1.运维网.com/attachment/201303/155010562.jpg
《AWS历次事故分析及启示》原文链接http://vdisk.weibo.com/s/txo-W
AWS历史上的4次事故说明了公有云或私有云，尚不够稳定，对设备、系统、技术等各个方面的要求还是很全面苛刻的，某一个忽略或不在意的点都可能产生雪崩效应，波及整个业务。由此可见运维团队的重要性以及技术能力的全面性。
网站运营事故的发生是不可避免的，出现故障也正是检验网站架构、运维团队能力的时候。当出现问题进行分析、排查、解决、恢复并进行故障根源详细的分析总结、完善，避免重蹈覆辙，使网站架构更健壮、稳定。
AWS出现的事故并不是昙花一现，也有可能在任何一个网站发生，我们更应该借鉴和规避类似事故。 网站应用的架构设计就应该将诸多方面考虑进去，以下是我的一些想法：
1、强化运维制度规范，避免“想当然”，减少误操作，对于生产环境的较敏感的变动，例如网络的扩容，服务器的上下架、硬盘的更换等，需要对操作的必要性、步骤流程、潜在问题的预估、指定操作人员及负责人员、操作时间的选择等以文档等形式进行报备审批后才能实施。
2、提高运维人员技能，知识的积累储备和共享，对新技术的敏感、研究储备。
3、IDC的选型（例如：网络质量的稳定性、超带宽容量的临时增加，机房电源的冗余不间断性、容灾性（如果一个机房故障，将业务切至其他机房继续提供应用）），服务器及网络设备硬件的稳定性（进行设备加电测试稳定后再上线使用），操作系统的选择（将操作系统安装在已经测试可用的服务器型号上，进行操作系统熟悉掌握及常用应用测试后再上线使用），应用程序（版本的稳定可靠性、安装目录、文件名、配置参数的规范统一性，同样前期需要经过测试的版本才能上线使用）。
4、运维工具的选择：安全的、统一的，甚至一些特殊配置也要标准化。
5、操作系统权限的控制、审计。
6、工作业务责任制，分配到人，明确岗位职责。
7、常见故障的处理文档化、标准化，提交至运维知识库，出现相同或类似问题即可到知识库参考，提高效率。一切以确定的、可行的为依据，减少模糊的、想当然的做法，避免人为操作失误。
8、业务上线的规范，开发完毕测试环境测试、审核完毕，然后再上线。
9、应用架构的设计：冗余性、可靠性、高可用性。
10、数据备份（配置文件及数据的备份机制、异地备份，备份的可用性定期进行自我检验）
11、系统、网络、IDC设备的硬防安全（定期自我检测或请第三放进行安全评估）
12、系统、应用的监控及监控机制的规范（完善监控内容、标准监控参数、报警发现通知流程、报警级别的划分）
13、未雨绸缪，对网站业务运营自我进行风险预估。
网站架构不可能一直能满足需求，也不可能一直是稳定的，他就像矛与盾的关系，随着生产发展而不断完善、优化。这也是运维团队的职责与重要性。
以上自己的一点想法，不妥之处还请指正，都是结合工作中接触到的一点思想认知吧，并没太具体的实操性。
页:
[1]