-
系统稳定性建设（3） – 高可用稳定性建设实践指南
文章目录 Toggle 1.概述2. 良好的系统架构和实现2.1 架构设计2.1.1 消除单点2.1.2 数据一致性2.1.3 强弱依赖梳理和降级 2.1.4 热点 或 极限值处理2.1.5 资金交易类系统要仔细考虑资损的风险2.1.6 离线数据流2.1.7其他异常情况处理2.2 容量评估设计2.3 运维方案设计2.4 安全设计2.5 高质量的代码实现3.团队研发运维流程机制4. 技术同…- 8
- 0
-
系统稳定性建设（1） – 如何做好系统稳定性建设系统
文章目录 Toggle 1. 背景介绍2. 故障源的分类3. 稳定性建设四要素第一要素：人第二要素：工具第三要素：预案第四要素：目标4. 稳定性建设四个方向第一个方向：根基要抓牢（45%）第二个方向：工作在日常（30%）第三个方向：预案是关键（15%）第四个方向：容量是核心（10%）3. 总结 1. 背景介绍 在移动互联网时代，用户群的积累比之前更容易，但同样，也会因为糟糕的用户体验，而快速流失用…- 4
- 0
-
2024年 互联网故障盘点，我们能从故障中学到什么？
2024年已过，让我们来盘点今年出现的故障。回顾这一年，我们经历了各种挑战和困难，但也从中学到了许多宝贵的经验。 在面对不确定性时，我们学会了更多灵活地调整策略，每一次解决问题的过程，都是对能力的一次历练。虽然路途不易，所幸我们在变化中成长，塑造更强大的自己，也对未来充满了信心和期待。 2024年发生的宕机事件 谁能想到，“崩”也成了一种上热搜的新姿势。回顾2024年，微软、腾讯云、支付宝、美团、…- 32
- 0
-
系统稳定性建设（8） – 业务团队系统稳定性的思与行
文章目录 Toggle 前言什么是SRE1，心态&态度1.1，谁适合做稳定性？1.2，业务团队如何支持稳定性SRE人员1.3，开发和SRE的区别1.4，SRE心态上的一些释疑1.4.1，疑惑1：做好了是应该的，出了问题就要负责任1.4.2，疑惑2：稳定性总是做擦屁股的工作 前言 2013年，当我第一次接触稳定性的时候，我是有些懵的，当时完全不知道稳定性是什么，也不清楚要做什么。在接下来的8…- 17
- 0
-
系统稳定性建设（15） – 各大互联网公司稳定性治理之线上故障处理
文章目录 Toggle 0x01 概述0x02 线上故障处理的目标0x03 线上故障处理的思路0x04 故障发现0x05 故障定位0x06 故障排除0x07 故障回溯0x08 线上故障处理的‘后勤保障’完善的监控/告警体系完善的日志 trace 体系完善的故障处理机制0x09 总结0x10 案例0x11 参考资料线上服务故障处理原则墨菲定律应急目标应急原则应急方法与流程发现问题系统层面监控包括应用…- 5
- 0
-
系统稳定性建设（14） – 稳定性治理思路与实践
想了想，还是把过往一段时间里，我们在稳定性建设中的实践记录下来，包含一些思路和方法，也算是一部大型踩坑记录，也只是一些实践过的野路子、野方法。 文章目录 Toggle 团队背景治理目标故障分级稳定性目标治理思路事前预防研发流程中的保障常态化治理专项优化故障发现基础组件监控服务监控链路监控业务监控流量监控故障恢复故障注入恢复手段扩容熔断/限流/降级多云多活技术治理之外的稳定性能力建设流程标准及自动化…- 6
- 0
-
系统稳定性建设（13） – AI赋能稳定性思路
在当今数字化时代，从云端服务到智能工厂，从金融交易系统到医疗信息系统，各种复杂系统如同现代社会的“神经网络”，其稳定性直接关系到社会运转的顺畅与否。一旦系统出现故障，轻则造成不便，重则引发重大经济损失甚至危及生命安全。因此，系统稳定性治理成为了一个至关重要的课题。而近年来，人工智能（AI）技术的迅猛发展，为系统稳定性治理带来了前所未有的机遇，它如同一位“智能守护者”，正悄然改变着我们对系统稳定性的…- 5
- 0
-
系统稳定性建设（5） – 稳定性设计系统的思考
文章目录 Toggle 1、职责2、交付流程稳定性保障（1）方案设计规范（2）代码规范（3）流水线建设（4）上线规范（5）交付流程观测指标3、线上稳定性保障（1）事故预防1. 运维基础能力建设2. 服务治理3. 系统能力预估4. 业务梳理及风险排查（2）事故发现&排查1.原则：可观测性（Observability）2. 工具3. 多维度监控、报警4. 线上问题发现（3）事故处理1. 处理原…- 41
- 0
-
系统稳定性建设（4） – 稳定性设计原则：简单、冗余、标准化、健壮
作者介绍 淇公 ，蚂蚁金服技术专家。热爱 java 和一些函数式语言，长期关注系统稳定性领域 文章目录 Toggle 一、差旅随想二、概述稳定性保障三、怎么做系统设计四、风险分析五、风险防范三板斧六、在此之外六、结束 一、差旅随想 因为 base 在分公司，需要经常去总部出差，所以搭乘飞机成了家常便饭，很多时候坐在飞机上会不由的感叹，设计制造这样精密复杂的机器的那帮人真的是了不起，他们是怎样保证这…- 3
- 0
-
2015.5·27支付宝大规模宕机事故反思学习
事故背景支付宝拥有超过4万亿年交易总额，是中国第一大第三方交易平台，约占中国整体社会消费金额的六分之一。2014年年11月，就有用户反映，支付宝钱包目前无法转账和提现，当用户使用这两项功能时会提示出现未知错误或创建交易失败，该问题在移动客户端以及电脑网页端均存在。 事故经过2015年5月27日下午4点半左右，陆续有多个地区网友反映，支付宝出现网络故障，账号无法登录或转账。打开余额宝后，不能显示余额…- 6
- 0
-
故障治理 – 运行无间：阿里巴巴运维保障体系的一种最佳实践
阿里巴巴全球运行指挥中心，GOC (Global Operations Center)保障阿里经济体的业务稳定运行的核心团队。我们负责了整个阿里巴巴全局生产系统的稳定性。就像业界经常提到谷歌的SRE，我们相当于阿里巴巴的SRE。 今天我的分享分为四个部分： 1、稳定性现状及挑战 2、运维…- 30
- 0
-
稳定性的灯塔：腾讯 SRE 质量运营体系建设实践
本文将从整体角度出发，探讨腾讯 SRE 质量运营体系是如何构建和实践的，以及建设过程中经验和思考，并进行总结和展望。 01 行业背景 稳定性建设是一件很让大家头疼事情，就像我刚开始入职做 SRE 时一样，面对稳定性建设总是觉得无从下手。Google 的 SRE 提供了一些指导方向，Google SRE 这本书的核心是引导大家如何科学地进行稳定性建设。在此基础上，我们决定在腾讯大规模采用基于 SLO…- 1
- 0
-
IT服务管理:告警治理 – 京东基于Zabbix告警治理优化实践
大规模Zabbix万台应用监控场景下，针对告警、可靠性工程实践经验；通过Zabbix二次开发，集成运维平台、工单、值班、自愈系统，通告警服务化、数据化，为业务保驾护航，保障稳定性工程落地。 京东集团是一家定位于以技术为本，业务为基，多场景的高增长型互联网公司。我们的运营团队隶属于京东集团的信息化部门，负责对内对外各BG、BU和相关子公司提供园区分支应用系统基础设施等IT解决方案。1SRE与告警的关…- 2
- 0
-
故障治理 – 京东科技之全链路故障诊断-智能运维实践
讲师介绍 张静，京东科技智能运维算法高级经理。硕士毕业于东北大学，持续深耕智能运维领域多年，带领团队致力于京东智能运维算法迭代，把智能算法能力落地京东线上横向业务场景，算法在监控、数据库、网络、资源调度等多个纵向场景取得突破，提升了产品和运维的技术竞争力。善于将实践中沉淀的技术与日常算法工作中积累的技术与创新总结成专利和IEEE论文，申请智能运维发明专利50余项，IEEE国际会议论文收录9篇。 分…- 1
- 0
-
经验教训 – 服务稳定性SLA-2015年阿里双十一惨痛的教训
文章目录 Toggle 618&&双11SLA服务等级协议单个服务稳定性集群稳定性专项测试稳定性建设小结 618&&双11 作为研发，尤其是后端研发，每年在618或者双11的时候压力特别大，他们祈求服务不要出故障，交易能正常进行，而且期望用户体验非常棒而不是卡顿404等。 但是有时候就是事与愿违，比如在2015年11月11日傍晚，大部分用户反馈购物失败的情况，负责双…- 3
- 0
-
经验教训 – 2024.4.8 腾讯云事件持续近87分钟学习经验
腾讯云发布了 4.8 号大故障的复盘报告。我认为是一件好事，因为阿里云双十一大故障的官方故障复盘至今仍然是拖欠着的。公有云厂商想要真正成为 —— 提供水与电的公共基础设施，那就需要承担起责任，接受公众监督 —— 云厂商有义务披露自己故障原因，并提出切实的可靠性改进方案与措施。 那么我们就来看一看这份复盘报告，看看里面有哪些信息，以及可以从中学到什么教训。 事实是什么？ 原因是什么？ 影响…- 5
- 0
-
2015.05.28 事件回顾，深入解析和反思携程宕机事件
携程网宕机事件还在持续，截止 28 号晚上 8 点，携程首页还是指向一个静态页面，所有动态网页都访问不了。关于事故根源，网上众说纷纭。作为互联网运维老兵，尝试分析原因，谈谈网友的看法 携程微博：5月29日1：30分，经携程技术排查，确认此次事件是由于员工错误操作导致。由于携程涉及的业务、应用及服务繁多，验证应用与服务之间的功能是否正常运行，花了较长时间。携程官方网站及APP已于28日23:29全面…- 5
- 0
-
实践案例 – 告警定级为告警治理核心，告警智能定级原理探索
很多大规模复杂在线服务系统，比如 Google、Amazon、Microsoft 和大型商业银行，包含数以千计的分布式组件，并同时支持大量用户使用。为了保障高质量服务和良好的用户体验，这些公司引入监控系统，智能收集服务组件的监控数据，比如指标/KPI、日志和事件等。通常工程师会根据经验设定一些规则用来检验监控数据，确保在服务异常时产生告警。这也带来一个问题，大型服务系统通常会不间断地被捕捉到大量告…- 2
- 0
-
故障复盘 – 语雀 P0 事故报告，军规红线9个字总结
故障时间：10月23日下午。 故障现象：语雀出现重大服务故障，持续 7 个多小时。 直接原因：数据存储运维团队在进行升级操作时，新的运维升级工具出现 bug。 具体细节：bug导致华东地区生产环境存储服务器被误下线，使语雀数据服务发生严重故障，造成大面积服务中断。 恢复过程： 因机器类别较老，无法直接操作上线，只能从备份系统中恢复存储数据。 数据恢复过程耗时较长，直到晚上 22 点，语雀的全部服务…- 43
- 0
-
数字化转型-IT运营为什么改变很重要
IT当前的运营模式在受到挑战。IT的复杂性和变化率的增长暴露了当前工作方式的局限性。在当今的环境中，可以全面管理IT服务和产品生命周期的数字管理系统对于成功至关重要。组织需要专门针对新数字化现实来设计的运营模型。 本文介绍ITIL® 4如何与IT4IT ™标准一起使用，来统一管理新的数字现实。 这两个框架的结合实现了更加简化和自动化的交付模型：一种利用了敏捷和DevOps方法的模型。 ITIL与I…- 9
- 0
-
经验教训 – 从10次宕机事件中，我学到重要的经验“不要心存侥幸,你担心的事情一定会发生”
今年的灾难事件有几点是比较深刻体会： 第 1 课：循环依赖会破坏你的运维工具流程工具与生产工具是结合一起，出问题往往是最不起眼功能环节，就是一棵螺丝钉 第 2 课：愚蠢的自动化强依赖于流程工具与自动化工具，应急时缺少了走火通道 第 3 课：现在是 2023年，数据库仍然很棘手灾难恢复后最耗时就是数据关系重建，数据完整性、一致性处理 第 4 课：分阶段慢慢部署变更需要遵循最小灰度原则 第 5 课：为…- 2
- 0
-
经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训
2月23日晚7点左右，微盟多个小程序显示出现未知错误，多次刷新仍未恢复正常。 基于微盟的商家小程序也都随之宕机，一度无法打开。从23日晚间起，宕机超过24小时，线上生意基本停摆的商家不在少数。 对此，官方一开始回应称设备物理故障，正在紧急抢修和修复。 2月25日，微盟集团(2013.HK)发布关于系统故障的公告，称SaaS(软件即服务)业务数据遭到员工人为破坏，并表示已向上海警方报…- 2
- 0
-
系统稳定性保障 – 哪儿网故障演练实践经验
大家好，我是来自去哪儿网的刘志志，19年加入去哪儿网，主要参与CI/CD平台建设，负责故障演练平台的开发。今天的分享主要分为以下三个部分： 一、背景&价值 如图所示，左边是近期发生的一件影响较大的事故：Facebook服务宕机。持续时长约7小时，造成了次日超过60亿美金的市值下跌，损失数额巨大。右边所展示的则是我们公司中某个业务线的服务调用关系。可以看到，整个链路非常复杂，如果其中某个链路…- 2
- 0
-
故障发生最重要的是快速恢复故障
故障发生时在故障发生时，最重要的是快速恢复故障。 而快速恢复故障的前提是快速定位故障源。因为在很多分布式系统中，一旦发生故障就会出现“多米诺骨牌效应”。也就是说，系统会随着一个故障开始一点一点地波及到其它系统，而且这个过程可能会很快。 一旦很多系统都在报警，要想快速定位到故障源就不是一件简单的事了。 在亚马逊内部，每个开发团队至少都会有一位 oncall 的工程师。在 oncall 的时候，工程师…- 5
- 0
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×