展开

关键词

计算宕机时我们该何去何从

如果你觉得最近服务出现问题的消息不断传出,那么恭喜你还没有被计算冲昏头脑。上个月很多用户都受到了服务宕机的波及。 Nest 谷歌旗下的智能家居公司Nest所提供的智能恒温器和摄像头的服务在9月7日宕机约三小时。这是Nest一周之内第二次出现宕机事件。 现在有很多人使用摄像头来作为安防手段,因此这次宕机时间也引发了摄像头作为安防手段是否可靠的讨论。 计算正日益融入我们的生活,可能有时候我们都意识不到自己正在使用服务。 正因为如此计算宕机的影响才更严重。我想,最近一个月发生的这些宕机事件给我们的启示有三点: 计算不是万灵丹,我们不过是租别人的计算机而已。 可以是另一家服务提供商,也可以是自己后备的数据中心。对于普通用户来说可能就是Skype和Twitter的替代产品了。 真心希望上个月发生的这些宕机事件只是个巧合罢了。

511100

公有宕机如何赔偿用户损失?

11月19日凌晨,微软Azure服务大面积宕机,在8月19日已有宕机先例的情况下,这次的事件让公众对云安全的关注再次攀升到了顶点。 随后,11月24日,微软在向服务用户发出的公开信中表示,将会通过SLA对Azure宕机中相关的受损企业进行相应赔偿。 一直以来,公有宕机后如何向用户赔付都是一个困扰服务供应商的难题。 首先,服务厂商不可能保证自己的服务100%无宕机,即使是号称永不宕机的大型机也同样存在风险;其次,用户的损失难以估量,关键系统与非关键系统、不同行业、不同企业规模造成的损失大小也不同,难以找到统一的衡量标准 由于上述两点,大部分服务提供商都没有提供相应的损失赔付条款,一旦出现宕机状况,用户的使用极易收到影响,甚至造成用户数据的丢失。 微软的SLA协议是对云安全模式的一种有益的探索。 一份合理的SLA能够让提供商、客户,以及约定的第三方监控服务对其进行度量。如果企业的提供商没能遵从SLA,通过预先设置的处罚机制将会补偿由于宕机对于企业业务产生的影响。

1.2K130
  • 广告
    关闭

    腾讯云校园大使火热招募中!

    开学季邀新,赢腾讯内推实习机会

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    避免在迁移过程中宕机

    在公共迁移期间,IT团队需要采取谨慎的步骤,以避免听到“系统宕机”这种可怕的提示。 随着组织迁移到基于计算的基础设施,IT团队需要在迁移过程中保持可用性。 但是,考虑到所有复杂性,在计算迁移过程中,防止宕机或最小化停机时间并不容易。计算团队需要考虑数据不一致,监控不同的软件版本,并检查其网络连接是否成功。 如果企业的应用程序崩溃,业务往往会停止。 停机时间的高昂成本是企业往往将最复杂的工作负载迁移到另一个平台(包括计算)的原因之一。 企业仍然快速地采用公共。 任何计算迁移过程都是艰难的,移动信息需要大量的时间和精力,即使生产和目标系统完全兼容。而企业的计算提供商运行的系统与其内部使用的系统相同的机率很小,因此迁移挑战呈指数级增长。 将工作负载移至计算时,企业面临诸多挑战,但公共供应商提供工具和服务来简化迁移流程。

    471100

    微软计算服务Azure全球大范围宕机

    北京时间8月19日消息,据彭博社报道,微软计算服务Azure的主要组件周一发生全球大范围宕机。 微软发言人克里斯蒂·莱万多斯基(Kristi Lewandowski)表示:“我们已经发现Azure服务的中断问题,包括虚拟机、服务、网站、自动化操作,正在与工程师团队一起努力,尽快解决这个问题。” 微软Azure主要与谷歌、亚马逊的计算服务竞争,8月份也遭遇过其它宕机问题。不过,计算服务在一个以上数据中心发生宕机并不常见。 这是自2013年2月一些存储工具停止服务以来微软经历的最为严重的Azure宕机事件。

    680100

    如何零宕机将本地 Kafka 集群迁移上

    为什么要托管 Kafka 集群? 自管理一个 Kafka 集群并非易事,尤其是在执行一些任务时,例如重新平衡 brokers 之间的分区,或者升级 brokers 版本等,这些必须认真规划和实施。 以下是使用 Kafka 平台,特别是 Confluent Cloud 的 4 个好处: 更好的集群性能和灵活性 其中的 brokers 分区的重新平衡让其不会成为性能瓶颈,可以轻松扩大或缩小集群容量, 零宕机迁移 在实时流量中执行迁移,就意味着必须进行细致的规划和实施。

    9720

    mysql宕机日记

    今天博客突然打不开,一看需要连接数据库的网站都挂了,静态网站没挂,猜测是数据库问题。

    11020

    AWS 再次宕机

    亚马逊AWS今天再次遭遇故障,这起事件影响了众多在线服务,包括 Twitch、Zoom、PSN、Xbox Live、Doordash、Quickbooks On...

    6310

    2018年的十大宕机事件,你中枪没?

    今年最大的服务宕机事件由市场三巨头主导:AWS、微软Azure和谷歌平台。 无论原因如何或最终影响范围的有多大,一旦出现宕机,企业对公有的信心都会出现动摇。 虽然没有是完美的,其在某种程度上的停机也是不可避免的,但是市场领先的供应商应该需要长时保持更高的标准。这就是为什么AWS、微软Azure和谷歌平台这三个巨头的宕机事件如此尴尬与引入注目。 宕机影响了谷歌的开发平台App Engine、Cloud Networking和Stackdriver,后者旨在为公有用户提供绩效与数据诊断服务。 但是对于全球最大的电商网站来说,失败就是失败了,这个网站是在据说是世界上最领先的上托管的。许多消费者乘兴而来败兴而归,得到的只有一个宕机通知。 这次宕机影响了许多需要身份验证而登录服务的用户,并横跨整个欧洲、亚太和美洲地区,从当地时间周日晚上11:39起开始影响Azure和Offic 365服务。

    48930

    哦豁,宕机了...

    Roblox 发生超长宕机,表示关键业务坚决不上 10 月 28 日,Roblox 发生了一次长达 73 小时的宕机事故。 Salesforce 工程师走捷径修 Bug 引起全球大宕机 Salesforce 是目前最受欢迎的软件应用程序之一。据报道该软件应用程序已被全球大约 150,000 个组织中的数百万名员工使用。 3计算相关服务提供商:一旦出岔子,“爆炸半径”就很大! 计算巨头 OVH 数据中心失火,360 万个网站被迫下线 3 月份,欧洲计算巨头 OVH 位于法国斯特拉斯堡的机房近日发生严重火灾,该区域总共有 4 个数据中心 (Strasbourg Data Center 谷歌全球宕机 2 小时 11 月 16 日,据国外媒体报道,全球最大的服务提供商之一谷歌(Google Cloud)出现了宕机,导致许多依赖于谷歌的大型公司网站中断服务。

    17960

    Facebook宕机的经验

    社交大佬Facebook最近有点烦,因为在美国当地时间4日清晨,有用户反映,再也无法刷新Facebook诸多社交网站,涉及到全球数十个国家和地区的用户,直到宕机近7个小时后,美国当地时间下午三点,Facebook 当地时间5日,Facebook表示4号一度出现大范围宕机故障的原因,是工程师错误地发出了一条指令,导致了错误的配置更改,切断了FB的数据中心在全球范围内的所有网络连接,但是目前没有证据表明用户数据因宕机而被泄露

    17640

    Redis宕机 快速恢复

    9059917216012421e8e89a4aa02f15b75346d2b7 为master数据库添加了一个监控 发现了2个slave(由此可以看出,哨兵无需配置slave,只需要指定master,哨兵会自动发现slave) 5、从宕机及恢复 20:09:33.509 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ taotaoMaster 127.0.0.1 6379 说明已经监控到slave宕机了 6、主宕机及恢复 哨兵控制台打印出如下信息: 2989:X 05 Jun 20:16:50.300 # +sdown master taotaoMaster 127.0.0.1 6379 说明master 服务已经宕机 2989:X 05 Jun 20:16:50.300 # +odown master taotaoMaster 127.0.0.1 6379 #quorum 1/1 2989:X 05 Jun 20:17:22.463 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ taotaoMaster 127.0.0.1 6381 发现6379已经宕机

    15220

    Kubernetes 零宕机滚动更新

    但是 Kubernetes Ingress 连接到实例的方式稍有不同,这就是为什么当客户端通过 Ingresss 连接到应用程序的时候,我们会在滚动更新过程中查看到不同的宕机行为。 零宕机 那么如何增强我们的应用程序以实现真正的零宕机迁移呢? 首先,要实现这个目标的先决条件是我们的容器要正确处理终止信号,在 SIGTERM 信号上实现优雅关闭。

    77321

    宕机了,缓存数据没了。。。

    第一个风险,执行写操作命令和记录日志是两个过程,那当 Redis 在还没来得及将命令写入到硬盘时,服务器发生宕机了,这个数据就会有丢失的风险。 所以是不可避免会影响主进程的性能; No 策略的话,是交由操作系统来决定何时将 AOF 日志内容写回硬盘,相比于 Always 策略性能较好,但是操作系统写回硬盘的时机是不可预知的,如果 AOF 日志内容没有写回硬盘,一旦服务器宕机 Everysec 策略的话,是折中的一种方式,避免了 Always 策略的性能开销,也比 No 策略更能避免数据丢失,当然如果上一秒的写操作命令日志没有写回到硬盘,发生了宕机,这一秒内的数据自然也会丢失

    15630

    Gitlab.com宕机始末

    接上集:Gitlab.com误删数据最近动态:恢复60% 14小时前 数据库恢复60%; 13小时前 gitlab在国外某非著名视频网站直播自己的数据库恢复进...

    60860

    谷歌多项服务出现宕机

    今年2月20日和1月24日也有多款谷歌服务宕机。根据该公司公布的应用数据,它的邮件存档和安全服务Postini Services在过去一个月也频繁中断。

    32280

    Mysql宕机临时处理方案

    在日常开发中,难免会遇到业务高峰期,到时mysql不可用,但是这个时候领导肯定要求的最低限度,就是让业务跑起来,今天我们就说说有哪些方案可以临时解决这种问题

    21720

    Cassandra集群删除宕机节点

    出现DN标志的就说明是已经宕机的节点了,也就是我们需要删除的节点 2.4删除宕机节点 我们通过以下即可删除 . /nodetool removenode 宕机节点的Host ID Host ID可以通过上面节点的详细查看到,这个过程会比较的漫长,查阅网上的资料,是这样的解释的,这里删除的节点并不是真的直接删除该节点 关心删除节点状态 的话,可以通过以下的命令进行查看 nodetool removenode status 如果删除过程实在是太长的话,并且数据无关紧要,可以丢弃的情况下,可以通过以下的命令 直接删除该宕机节点

    51720

    Gmail全球大规模宕机

    整理 | 非主流 出品 | AI科技大本营(ID: rgznai100) 今天(3 月 13 日),Google 的多项服务在全球范围内出现了不同程度的宕机,包括 Gmail、Google Drive、 据悉,此次宕机涉及范围较广,对全球用户都造成了影响,包括美国、欧洲、亚洲、澳大利亚和南美洲等地区。

    30320

    CloudFlare公共DNS服务遭遇“宕机

    94140

    相关产品

    • 数据传输服务

      数据传输服务

      腾讯云数据传输服务(DTS)支持 多种关系型数据库迁移及 NoSQL 数据库迁移,可帮助用户在业务不停服的前提下轻松完成数据库迁移上云,利用实时同步通道轻松构建高可用的数据库容灾架构,通过数据订阅来满足商业数据挖掘、业务异步解耦等场景需求。 

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券