支付宝事件 支付宝事件描述怎么填写
最近互联网也很有意思，一个又一个的失败。我们一起来复习一下。2015年5月11日晚21: 00左右，网易旗下网易新闻、云音乐、易信、有道云笔记等移动应用无法正常刷新，网易名下游戏
最近互联网也很有意思，一个又一个的失败。我们一起来复习一下。
2015年5月11日晚21: 00左右，网易旗下网易新闻、云音乐、易信、有道云笔记等移动应用无法正常刷新，网易名下游戏全部瘫痪。失败原因:骨干网被攻击。
2015年5月27日下午，有用户反映其支付宝出现网络故障，账户无法登录或支付。故障原因:光纤断了。影响持续时间:4小时
2015年5月28日上午11:09，携程官网及其APP无法打开，5月28日23:29全面恢复。整个过程花了12个多小时。故障原因:误操作。影响持续时间:约12小时。
2015年6月5日，今日头条网首页和APP无法访问，直接提示500错误。失败原因:未知影响持续时间:约30分钟。
2015年6月15日12: 30，知道网络打不开，直接提示错误【服务器提出问题】。13点45分左右，知乎页面恢复正常。故障原因:机房故障持续时间:60分钟左右。
发生了什么事？是什么让我们的互联网业务如此脆弱？运营商总是在背后做坏事是真的吗？还是我们的系统架构薄弱？还是我们的运维能力真的很弱？如果我从广义上来看这个，我也会归结为运维。但对于以上故障，从运维的角度，我还是会说，官方的结论不够专业。我希望内部不是这样。
1.网易表示，骨干网收到网络攻击，影响其业务。那天网易的业务好像也受到了影响？
2.光纤中断影响四个小时。从这样一个核心业务出发，首要原则一定是恢复业务。我觉得支付宝即使不做双活，也一定会有可用的备份中心。怎么还没剪？里面肯定有问题。但是，阿里滥用的地方，他可以把负面的东西变成正面的。他们把“5.27”变成了技术支持日，并进行宣传。
3.携程事件，我之前写过一篇文章【携程事件:运维债务深度分析及解决方案】，不详细说了。
4.今日头条，500个内部错误。这条新闻能让自己上头条，却没有正式的解释。从500误差的恢复时间来看，有点长，500误差是一个非常好的定位。我的怀疑是数据库的压力不够，导致后续的扩展和变更，只有数据库子库和子表的扩展时间需要这么长的时间。另外，头条君首页直接给出一个500错误，技术描述非常不友好。我建议你把服务降级，推一个大众版的新闻，不要做个性化推荐。这可以通过制作缓存来解决。
5.Zhihu故障，简单来说就是机房故障，太简单了，但我觉得最大的可能是Tengine后台服务超时，而不是简单的机房故障。
每次出现故障，其实都是在伤害我们的用户。内在的表达就是可用性或者质量。因此，我们必须给予足够的重视，我们需要将其转化为宝贵的经验。那么到底什么是可用性和可靠性呢？影响可用性的因素有哪些？运维如何提高可用性？等一下。
首先，什么是可用性和可靠性？
可靠性是系统在给定的时间间隔和给定的条件下正确执行其功能的概率。可用性是指在任务执行的任何时候，系统能够正常工作的概率。我们先来看一些指标定义:
1.MTBF——全称是平均无故障时间，即平均无故障工作时间。它是新产品在规定的工作环境下启动到第一次出现故障的平均时间。MTBF越长，可靠性越高，正确工作能力越强。
2.MTTR-全称是平均修复时间，即平均修复时间。它是指可修复产品的平均修复时间，即从故障到修复的周期。MTTR越短，可恢复性越好。
3.MTTF-全称是平均故障时间，即平均故障时间。系统平均能正常运行多久才会出现一次故障？系统的可靠性越高，平均无故障时间越长。
可用性可用性= MTBF/(MTBF+MTTR)。通常，我们使用N 9s来表示系统可用性，从停机时间的角度来理解更好。如果以全年为一个周期(24*365=8760小时)，三个9(99.9%)意味着全年停机时长为525.6分钟，四个9(99.99%)
从这些时间指标，我们可以反向推导出IT能力不足的地方。比如一个故障恢复时间长，那一定是自动恢复、运维意识、处理流程、系统架构等地方出了问题，导致停机时间长；平均故障时间很短。系统的可靠性肯定有问题，比如技术设计，依赖的硬件环境等等。
二、影响可用性的因素
影响可用性的因素有很多，但我们可以从几个维度来看，比如人和组织、流程、技术和业务管理。
1.人员和组织
其实这个地方可以说说你这种类型的人和组织。领导重视吗？你重视运维吗？组织有没有认识到它所带来的价值，并将其视为核心竞争力之一？面向用户的业务能力和IT能力衔接好了吗？是否建立了用户质量的组织文化？等一下。
2.过程
这个过程就是理清多个角色的关系和职责。首先，我们要看这个过程在面对失败时是否起到了积极的作用，比如它能保证失败信息的准确传递，同时保证处理者的角色和职责明确。其次，检查流程是否可以自动驱动，而不是人工驱动。人是不可靠的来源！最终希望形成一个自动化、标准化的流程，不容易被异化，能够保证预期的执行结果一致。
3.技术
很多时候，我们看到的技术是运维技术。其实恰恰相反，对于互联网业务来说，影响其高可用性的一定是业务IT技术架构。所以需要遵循很多原则，有些原则需要有普遍的参考价值。比如服务降级、灰度释放、过载保护、服务公示等等。这些方法是否已融入R&D的建筑设计理念以及运营和维护中？优先考虑的是真实产品的功能需求，而不是可操作性，最终是业务的质量。
4.企业管理
把你的IT能力作为业务能力，你可以把它转化成很多业务指标，比如质量、可用性、用户体验、用户满意度、成本等。通过这些面向业务的指标，您可以更好地将IT能力与业务联系起来。否则很容易在组织内部形成“是支持部门”而不是创造价值部门的认识。这一点也很重要，就是IT部门要充分意识到自己的能力与业务直接相关，需要增强业务敏感度。
第三，如何提高系统的可用性
我刚才提到了影响可用性的因素，分为四个方面，但是我想提高系统的可用性。换个角度，我可以把握一些核心原则(其实更多)。
1.在故障发生之前，建立操作和维护质量仪表板。
我们必须建立一个运维数据广告牌。这个广告牌的数据要在业务、R&D、测试、运维上达成一致，让大家对这个数据有足够的重视，这样数据才会有驱动力。建议这个地方不要有太多的核心数据指标，因为涉及到很多团队，大家不可能一致理解，尤其是跟管理层沟通的时候。指标太多，容易失去关注的焦点。
通常的做法是将可用性作为运维的数据看板。计算可用性既有简单的方法，也有复杂的方法。简单的方法就是在监控系统中设置一些探头，模拟用户监控。最后可以得到故障的持续时间和可用时间，这样就可以建立每天、每周、每月、每Q的可用性，划分业务和服务(粒度更细)等。复合形法以仿真数据为基础，以事件系统记录的时间数据为评价标准。此外，可用性可以上升到质量的层面，涉及更多的评估维度(成本、用户体验、满意度)和更多的数据获取来源，有的来自客服系统，有的来自舆情监测，有的来自运维能力系统，有的来自事件系统等。，但最后提出的指标是一个质量。
运维数据看板，最好能成为生产研发端KPI的一部分。同时，在运营和研究端也需要周期性的把这些数据推送给他们。有了KPI和持续滚动机制，就可以建立良好的业务质量意识。
我一直觉得数据文化是运维打造影响力的重要一步，不然你就是个辅助部门！
2.在故障发生之前，设定技术标准和要求。
运维需要和研发一起建立整体的技术标准和规范要求，这一点腾讯做得很好，把海量服务提炼为若干关键词【海量服务运营之道】，可以在网上搜索。当然，很多企业要准确理解这些关键词会非常困难。所以从运维的角度，我们需要制定一个路线图，最终服务于这个技术目标。比如我前面提到的【运维三部曲】，里面提到先做标准化(修炼运维内功)，再做公共服务(修炼架构内功)，最后服务无状态(修炼业务内功)。
运维必须以标准化为核心任务，建立标准化的运维环境，建立标准化的技术栈(和R&D确认)，建立标准化的高可用方法论。最后，这个业务的可用性一定要保证。
3.当故障发生时，恢复是第一要务。
当故障发生时，“恢复、恢复、恢复”必须时刻记在运维人员的脑子里。
在故障时刻，定位故障原因是一个禁忌，这往往使故障的持续时间不可控，因为这将直接影响MTTR(平均修复时间)，并影响用户的业务使用。但是，有些人会有疑问。如果他们不知道问题的原因，他们怎么知道如何解决问题？凭经验，你一定有一些简单粗暴的原理来隔离故障，比如服务器重启，链接禁用，DNS切换等等。
4.出现故障后，请小心恢复。
每次故障发生后，需要运维人员带头排除故障。我们只是说我们的恢复是重中之重，所以我们可能不知道失败的根本原因。这时，我们需要运维、测试和R&D来仔细看看整个故障过程，看看到底是哪里出了问题？基本上也是从刚才说的四个方面来评价的。不断的审视自己的运维能力和IT，说“失败是运维最好的老师”也是这个道理，可以不断的驱使我们走向更高的成熟。
是运维的主要负责人复检，也就是找根源。根本原因不同于故障现象。比如故障现象是交换机故障，根本原因是技术架构无法容忍交换机故障，根本原因是运维对这种故障缺乏有效的临时响应机制。
复盘是为了让我们走向更好的运维阶段！
5.故障发生后，恢复的措施是有讲究的。
故障恢复后，一定会写改进措施。这些改进有一些精巧的措施。看过一些失败报告，很不理想。我的亲身经历如下:
故障措施必须是可实施的、具体的，要落实到具体负责人和具体时间。
失败的衡量标准必须首先是技术，然后是过程，最后是人。
故障措施可分为长期措施和临时措施。
故障措施必须只扣故障的根源，避免流于形式和表面。
故障措施应不应该“亡羊补牢”，需要全面细致的分析。
失效措施必须保证持续随访。
一叶可以障目，但也可以一叶知秋，就看我们是否真的去认真对待。你们真的重视故障了么?你们真的重视运维了么?故障不能带来运维人的春天，从根本上去意识到运维的重要性，那才是运维人真正的春天。
