覆盖云原生、数据库、前端、架构四大领域,这本精选集你不能错过! 了解详情
写点什么
  • 发布
  • 评论
  • 划线
  • 收藏
  • 关注
  • 全部分类
阿里稳定性指标1-5-10解读
阿里稳定性指标 1-5-10 解读

1-5-10 的指标解读:1 分钟发现、5 分钟处置、10 分钟恢复

监控治理有效性评价体系

当一个中大型互联网公司,每天由监控系统发出大量报警,而故障却始终无法及时发现的时候,如何能够快速找到问题的根源,如何改进,以及如何度量改进的效果,这一系列的问题就会摆在大家面前,本文基于作者在多家公司的监控治理经验,从评价体系角度出发,整理

MAC系统初始化
MAC 系统初始化

不需要的软件需要点击隐藏已购项目这样才能让下次重新安装时无脑安装

HTTPS证书过期导致的故障
HTTPS 证书过期导致的故障

数字证书的安全基于它所使用的非对称算法的安全,而算法的安全是相对的安全,是指现在可预见的年月里,如 10000 年无法破解。但随着时间的推移,技术的进步,它就可以被很快的破解,所以算法的安全是基于时间的。SSL 证书的使用寿命不得超过 27 个月。

我们是如何将 ToB 服务的交付能力优化 75%?
我们是如何将 ToB 服务的交付能力优化 75%?

ToB 服务交付的方式分为公有云部署和私有化部署两种。其中,对成本敏感的中小企业往往采用公有云部署的方式,从而尽量减少成本。客单价较高的大型企业、政府、银行和事业单位,考虑到数据隐私、安全、合规等要求,往往采用私有化部署的方式。

从二十个严重的配置故障中我们能学到什么?
从二十个严重的配置故障中我们能学到什么?

配置故障是运维人员在工作中经常会遇到的问题,如何才能避免配置故障的发生呢?本文作者列出了自己职业生涯遇到的 20 个不同类型的配置故障,并分析了故障发生的原因,提出了相关的解决方法。

混沌工程:一年间重启5000台机器后学到的7个经验
混沌工程:一年间重启 5000 台机器后学到的 7 个经验

当产品丰富度提升了之后,大家都担心一个问题,在这么短的时间内,上线如此多的产品,质量是否能够做到最好?于是,混沌工程作为提升产品质量的头号工程,便应运而生。

上云了,如何保障云数据库的高可用?
上云了,如何保障云数据库的高可用?

朋友和我吐槽,自从他负责的系统上云后,在云数据库上经历了好几次故障,而事后的故障复盘,居然都是他们自己的责任和问题,这让他很被动。

混沌工程落地的六个阶段
混沌工程落地的六个阶段

本文将混沌工程总结为六个阶段,并对各个阶段的落地过程加以总结,希望能够对大家落地混沌工程有所帮助。

Puppet:维护运行环境一致性的利器
Puppet:维护运行环境一致性的利器

每次我提到配置管理工具,有些同学就会问类似的问题:容器化时代和 Serverless 时代,还需要配置管理工具吗?

预案三板斧之降级大法
预案三板斧之降级大法

目前比较通用的降级方法为以下三种:页面静态化、请求异步化和计算本地化。

预案三板斧的限流大法
预案三板斧的限流大法

限流是针对请求的各种特征,多维防御 + 纵深防御,从而限制流量,实现对服务端资源的合理使用。

个人成就
  • 发布了 19 篇内容

    57941字, 被阅读 27.0

  • 获得了 254 次赞同

    获得了 74次喜欢, 获得了 180 次收藏

  • 参与了 85 次互动

    互动包含发布评论、点赞评论、参与投票等

TA 关注的
还没有关注其他内容哦
最新评论
  • Geek_45c2deaz 是什么?

    跨 AZ 部署最佳实践之 Zookeeper

  • 焦振清还需要增加一下因为锁导致的故障

    上云了,如何保障云数据库的高可用?

  • 宫保奇丁请问 [报警周期优化,避免瞬报] 小节中的 UI 图是什么工具呀?

    摆脱无效报警?十年运维监控报警优化经验总结

  • 焦振清每家公司或者公司内较为独立的成规模的业务,都要跑出自己的变更节奏,什么时间该干什么事情,这应该是非常明确的。例如说,每周二和每周四上线,且每次上线的时间点固定就是 xxx 时间,然后进行倒推,你什么时候提测,什么时候提交代码,什么时候做 code view,基本上都可以慢慢的形成一个固定的节奏和预期。这次如果我 delay 了,我也清楚下次什么时候可以上线,真要出现了问题,我们也可以进行快速回滚,回滚到哪个版本也比较清晰和明确。

    从美国 FDA 新药审批制度看分级发布最佳实践

  • 焦振清大家经常会讨论说,升级完毕一个机房后,对第二个机房,是直接全量升级,还是说按照单台,多台,全量的顺序升级。 从经验的角度看,升级单个机器,主要是为了检查一些基本问题,程序是否可以正常工作,有没有 coredump,端口是否正常等等较为基础的问题,毕竟一台机器,也难以发现一些系统整体层面的问题,除非说太明显了,太低级了。 再加上,其实,每一个分组都是要消耗时间的,因为每一个分组都需要检查,检查都需要数据的积累和计算,这都是时间,因此,如果在第一个机房之后的所有机房还需要有单台的升级策略,那么整体的升级耗时将会增加很多,我个人并不是特别建议 建议的灰度方式:线下环境 ->线上小流量机房(单机,多台,全量)->线上每个机房(按照并发度进行实例升级)->达成全量升级完毕,并且在每个升级间隔,是需要做效果检查的,而不是等着,效果检查不一定要拦截变更,虽然这是理想情况。

    从美国 FDA 新药审批制度看分级发布最佳实践

郭大侠深度解析 OLAP 引擎趋势

郭大侠深度解析 OLAP 引擎趋势

焦振清