称心常识网宕机是什么意思，宕机是什么意思怎么读？
本文最初发布于 byrayray.dev 网站，经原作者授权由 InfoQ 中文站翻译并分享。
在职业生涯中，我跟事故仿佛“结下不解之缘”。也许，这是命运使然，或者我喜欢看到事物是怎么出问题的。也许，罪魁祸首是我？不管出于何种原因，这种经历给我很大帮助，让我总结出一套应对事故的方法论。
从那时起，Matthieu 就时常鼓励我向更多人分享这些理念。于是我接受了他的建议，写下这篇文章。
如果你搜索过应急响应（Incident Response）这个概念，会发现有很多结果是关于应急角色（incident role）的。Atlassian 上有一些优秀的文档很好地解释了这些概念。
简单来说：
应急角色可随着你响应团队的成长而帮助扩展应急规模。角色有助于分离职责，确保应急工作的各个方面都有专人值守。定义这些角色可以让每个人都清楚自己应该做的事情，以及对彼此应有的期望。有两个角色是你必须关注的：应急指挥官，是针对事故所采取措施的唯一联系人。他们不需要亲临一线采取行动，但是在重新启动服务器之前，请先与他们做好确认。这样就避免了某位好心办坏事的同事说出那句经典的“糟了，我不知道你正在将数据库还原到这个节点上”。联络角色。这个角色是必不可少的，也是缺少结构化应急响应流程时最容易被遗忘的角色。你当然不能重蹈覆辙，而是要尽早任命某人来管理联络事宜，并确保所有响应人都主动分担与他们的联络工作。永远不要要求人们同时做调试和联络工作，这样会分散他们的注意力，结果两件事情都会搞砸！文献中还定义了其他许多角色，但是只有当你的团队对每个角色的含义有深刻的了解时，这些角色才能派上用场。我认为，指挥官和联络人是至关重要的——在没有足够培训的前提下增加粒度会扰乱应急工作，并削弱你的响应能力。
如果你对想要使用的角色感到相当满意，并且你的团队在所有角色上都有良好的实践经验，那么你就迈出了高效响应的第一步。可是，现在有了各种角色，你的团队该如何解决问题呢？
第一，快速找到流血部位
首先，找出流血部位（what is bleeding）。如果你可以尽早确定应急响应的范围，就意味着你接下来的措施就更可能解决问题。
尝试：
确定是哪些系统发生了故障，然后检查各个依赖项，判定问题是由上游组件还是下游组件引起的；一定要警惕假设。对于你从第三方获得的所有信息，一方面给予信任，另一方面请务必验证。记录你所做的验证工作，例如你运行的命令和运行的时间。错误的假设可能会让你的响应偏离正轨，因此请尽力避免它们。找到技术上的问题源头后，请考虑做一些影响分析。不要因为这部分工作而影响进度，但如果有人愿意，请让他们估计影响的范围——哪些人受影响，人数有多少。对影响的不正确理解可能会导致错误的决定，而清楚地了解受影响的对象可以帮助组织的其他部分（客户成功、客户支持等）做出适当的响应。
一旦团队理解了事故的性质，就可以开始止血（stop the bleeding）。换句话说，你的目标应该是尽快阻止当前的麻烦，并将清理工作推迟到压力更小的时间段再做。
第二，确定行动的优先级
为此，我们需要确定行动的优先次序，以尽可能取得最佳的成果。请注意“尽可能”这一短语：应该立即采取能够迅速实施的例行补救措施，就算你怀疑它只能解决部分问题也无所谓。
这些措施包括：
回滚到一个确认没问题的版本，就算你觉得自己很快就能写好修复程序，也可以在回滚后压力较小的情况下再徐徐而图之。采取措施保护关键系统，就算牺牲其他一些不太关键的流程也可以。如果某个端点导致整个系统出现故障，请在这个端点恢复了关键服务后立刻no-op掉它。充分调动团队，并主动应用你认为风险较低的修补程序，就算你怀疑它可能无法解决全部问题也不怕：缩减不必要的队列、冻结部署、重新启动服务器。充分调动人力就可以快速做尝试，前提是其他响应者要继续分析问题的根源，同时假设简单的修补会无济于事。
这样你就应该大致了解自己的团队应该做什么事情了。现在的问题是，他们应该如何协作来执行这些任务呢？
第三，使用高效率工具、创建应急文档
鉴于沟通交流在应急响应工作中的重要性，你需要一款高效率工具来传递即时消息并记录操作日志。
可以使用 Slack（或其他有着相同功能的软件）：
在任何事故中，第一项操作就应该是创建一个消息频道。有很多工具（monzo/response、Netflix的Dispatch）可以为你自动创建它（还有很多其他东西），但就算你得自己手动完成这一步，也一定不能跳过它。为了准备好这个通道，多花费一分钟的停机时间也是值得的。我坚决反对私有应急响应频道。公司内部使用的公共通道可以提升信息访问的便捷性，从而加强你的响应能力。这样可以避免很多会让你头痛的协调（有一次，我见过两支彼此独立的应急团队在处理同一个事故，但他们之间根本不知道对方的存在……）每当你要执行破坏性操作（例如运行一条命令或重新启动某些资源）时，请向频道发送告知消息。这不仅可以让整个团队提高警觉性，而且为善后阶段编写事故日志提供了宝贵的记录。
即时消息非常适合用来传递带有时间戳且不应更改的信息。对于你希望随着应急工作的进展而调整的内容，请在你喜欢的协作编辑器中创建一个应急文档（Google 文档、Dropbox Paper、Notion 等）：
你的组织可以草拟一些包含所需结构的应急文档模板：也许你有报告职责，或者有特定的沟通流程？全都放在这里，这样只需点击一下即可从这些模板创建文档。特别是针对大规模事故的应急工作中，应急团队会有人员轮换，这时候这些文档可以充当人员进入应急团队的切入点。让管理通讯的人员来管理这些文档、维护一份重要事件的时间表，甚至在事故特别复杂时起草一份执行摘要。让你的技术团队将代码段或相关日志行贴到文档附录中，这样每个人都可以对齐同一份应急工作的中心视图。
聊天记录和应急文档结合在一起能成为强大的工具组合，可以帮助协调响应团队，同时为视察工作的投资者提供透明度。还有一点好处是，等到尘埃落定，可以很容易地将这些?内容重塑成一份善后报告。
第四，注意人为因素
最后，也是最重要的是人为因素。人们在承受压力时会做出错误决定，而沉浸在应急工作中会让你完全忘记照顾自己。在这方面，你应该以身作则，并强硬地要求你的团队成员照顾好自己的身体状况。
这里要考虑的一些事情：
减轻压力的一种有效方法是休息，远离屏幕，然后深呼吸。主动带领你的团队和你一起停下来，这样就会减少匆忙之间搞砸事情的潜在风险。一般来说，只要出现以下情况就暂停一下：有人呼你。不必太长；仅仅十秒的呼吸就能提醒你的身体一切尽在掌握，并降低肾上腺素水平。当生产故障停止时。警报平息并且情况看起来稳定后，请让整个团队休息一下。大多数事故都需要很多后续工作：在开始这些流程前，请让自己休息至少15分钟。跟踪过程中，在开始执行任何类型的流程之前，例如“X群集的恢复”。让大家在开始做任务列表前先呼吸些新鲜空气，让每个人都能回点血，避免流程出错或超时。一定要对应急指挥官做好培训，让指挥官及时撤出精疲力尽的响应人员。一项重要的工作是在人们饥肠辘辘之前订好外卖。也许应急响应团队会大声抗议，说他们根本用不着吃饭，可是等外卖上桌了，你就会看到他们狼吞虎咽的样子了。
这份列表缺失的内容还有很多，但你可以把它当作一个入门包，也可以作为经验丰富的人员在制定应急响应流程中关键环节时的一个参考。
只要记住：深吸一口气、关照好同事、批判系统而非人员、不要着急。祝大家好运！
这篇文章中缺少对善后分析、事故发生前的准备工作，以及在安全性、数据完整性、可用性之间如何权衡的内容。如果你有兴趣听取我对这些观点的意见，请在 Twitter 上联系我，我很高兴与你分享。
原文链接：
https://blog.lawrencejones.dev/incident-response/index.html
延伸阅读：
QUIC进入IETF最后征求意见，互联网的又一次巨大飞跃-InfoQ
关注我并转发此篇文章，即可获得学习资料~若想了解更多，也可移步InfoQ官网，获取InfoQ最新资讯～
以上内容就是小编分享的关于宕是什么意思.jpg” />
网友提问：
宕机是什么意思，宕是什么意思？
为什么服务器的宕机一般都发生在凌晨使用率最低的时候？
优质回答：
来自16年经验老程序员的靠谱回答。
主要有以下几个原因
1.凌晨时服务器很忙
首先，确实服务器的宕机一般都发生在凌晨使用率最低的时候，但是这个使用率只是针对用户而言的。
实际上，在凌晨的时候，服务器是很忙的。主要忙哪些事情呢？主要是一些定时任务，还有数据库备份等。很多比较耗时的操作比如报表统计都会安排在半夜，以免半天影响正常业务，所以这个时候，服务器都是在高负荷运转的，容易产生事故。
2.一般晚上的时候会上线新功能
同理，发布新代码或者更改功能，也会选择在晚上的业务低峰期。无论前期的测试工作做的多么到位，也难免会隐藏一些bug，到了凌晨，这些bug（比如死循环）已经跑了一段时间了，在无人值守的情况下就可能触发各种故障。
如果上线时间比较短还好，遇到更新比较大的情况下，程序员奋战到大半夜，这个情况下人是很疲惫的，更容易忙中出错。
3.无人值守导致修复变慢
比如死循环和内存泄漏，是需要经过一段时间才能表现出来的。白天有人实时监控，自然出现故障的几率比较小，就算出现故障了，也能很快修复，让用户无法觉察。
4.凌晨是黑客作案高峰期
夜黑风高，杀人越货。这个时间点是正常人休息时间，而黑客则选择在这个时候活动，不论是安全攻击，或者是DDOS，都可能造成服务器故障。
其他网友观点
计科专业从事嵌入式软件开发多年，最近因为公司需要搞后台研发，经常选择升级的时机放在凌晨，而且大型的数据处理也是放在这个时间段内，经常发生的服务器宕机也是在这个时段。都是在用户使用少的时候开始折腾，折腾的次数多也就容易出现服务器问题。由于做的是物联网设备，在工作中遇到的宕机主要有这么几种情况，对大量数据的操作导致CPU占比在一段时间内骤增从而导致数据接收模块出问题，导致系统监控出现问题，很多设备信息检测不到了。
对数据库的操作太频繁导致效率的下降，也是影响系统性能很重要的一部分，其实服务器也是普通电脑的构成，主要的资源是CPU和内存，这两个因素无论是哪种都有可能导致系统的崩盘，如果是CPU被占满了，系统的反应会变得异常缓慢，时间长了可能还会慢慢缓过劲来，内存如果占满了那么会导致系统的崩溃，直接运行不下去了，其实宕机核心点不会跑出这两种因素。
现在就常见的服务器宕机问题做个归纳总结：
1.磁盘空间被占满，现在程序员运行的时候都习惯于带上log打印，如果时间长了加上没有清理的机制早晚会出问题，这个错误在平时运行过程中经常出现，如果使用的云计算服务器通常在系统崩盘之前都会发个短信，通知你的系统处于崩溃的边缘。
2.并发性能问题，如果多个人同时操作一个数据库或者数据块，会导致系统假死状态，这种属于争抢CPU资源问题，可以通过增加硬件配置以及优化软件代码的效率去解决，数据量如何足够大就可以考虑分布式的管理
3.数据受损或者被破坏导致系统崩盘，所以常见的做法是都会配置备份盘，出现问题抓紧拿到备份盘来顶上，现在公司使用的是阿里云的服务器，稳定性相比之前好太多了，中间换过电信云，腾讯云虽然价格低点，最后受不了直接换成阿里云，再也不想换回去了，数据的稳定性永远是第一位的。
4，一些没有必要的误操作，很多时候是因为程序员或者运维人员的误操作大致服务器大面积的宕机，这种事件在很多云服务提供商身上都发生过，根本层面还是管理问题。后台管理的任何细节都有可能
服务器宕机查找问题的几个线索：
1.看看服务器是不是存在内存泄漏问题，有些时候重启机器开始还能正常运行弄了一段时间之后就会变得非常缓慢，十有八九都是内存的问题
2.是否有黑客入侵造成，有些非常关键重要的数据也是黑客最感兴趣的，一般来讲这种概率不是很高
3.是不是数据库死锁导致的，访问量过大导致，连接数过多造成的。
服务器宕机一旦发生就会引起用户的无数的投诉，无论在什么情况下稳定永远是第一位，现在大的功能升级除非已经百分百验证成功，否则引起的后果不堪设想。
希望能帮到你。
其他网友观点
虽说在凌晨的时候，使用系统的用户非常少，但是服务器在这个时候要做的工作可能一点儿也没有少：
数据批处理操作通常会集中在凌晨进行：例如很多公司都会在晚上进行对账操作，或为第二天的业务操作做一些预处理；或批量把业务系统的数据抽取到分析系统进行数据分析等等；
很多公司都做不到在线升级和灰度发布，所以系统升级经常安排在半夜，升级完只能做一些简单的验证，测试覆盖度的不足，也可能会导致遗漏一些BUG，最常见的一个问题是忽略了生产环境和测试环境数据量的差距，导致出现性能问题；
服务器操作系统、软件的升级通常也会在晚上进行，这些操作也会带来宕机的风险。
再说一个很久以前看到的，同行们分享的服务器宕机的经历，有些经历非常之神奇，大家就当段子看吧（为了方便，我就按照第一人称来讲述）。
我们服务的甲方是一家医院，机房就在医院的楼中，最近机房的服务器经常性的发生宕机，公司的工程师去了几次也没有发现问题；后来公司被折腾的没办法了，决定让一个工程师晚上住在机房，看看半夜机房中究竟发生了什么事儿，想着就算找不到原因，也能在服务器宕机后第一时间重启。
后来发现原因，到了凌晨三四点的时候，机房门打开了，进来一个值夜班的小护士，看了一眼说：“又没有人，开着空调不浪费电么？”然后就把机房的空调关掉了，然后气温上升…
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
其他网友观点
这里需要说明一下，服务器宕机是什么意思呢？我们日常说的“宕机”中的“宕”其实指的是英文“down”，宕机表示当前服务器或服务无响应或者不在线状态。
服务器的宕机可分为人为控制的宕机、不可控的宕机。这两者有什么区别呢，下面来具体说明一下：
1、人为可控的宕机行为
服务器长时间的运行可能会带来一些（非致命性）问题，又或者我们需要对服务器进行软/硬件的升级维护时，可能需要停机或者重启操作。这种情况下的宕机是可控的，在我们的计划之内。
2、不可控宕机行为
这种因素就很多了，比如说服务器突然蓝屏、服务异常崩溃、突然断电断网了，这时候服务(器)就无法正常提供服务，这些都是不可控因素导致的。
而在我们的日常运维工作中，计划性的宕机维护一般都选择在半夜来做这些事，为什么呢，原因主要有这几点：
1、减少对用户的影响
凌晨大家基本上都休息了，用户量较白天来说小得多，所以选择在此时进行系统及硬件的维护导致的宕机对用户的影响较小，就算有影响也只是影响小部分用户。
2、有足够的时间来处理故障
在凌晨进行维护，就算有问题，技术人员也有足够的时间（比如说：00~05点）去处理故障。如果换成在日间维护，服务(器)宕机1小时以上投诉单全都过来了，压力很大的。
以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！
其他网友观点
首先纠正题主，服务器在凌晨的使用率不是最低的，反而可能是最高的。
服务器故障为什么经常发生在凌晨？有点闹鬼的嫌疑，其实不是。
在互联网时代，低头族、夜猫子，已经成为名门望族，他们的发展壮大改变了很多曲线。
1，凌晨是业务高峰期的拐点
单次故障发生的时间点是偶然的，但是故障多发时间段是必然的。从统计数据看，大部分业务的用户活跃度在晚间达到峰值，零点之后开始降低，所以业务处理量在拐点附近达到最高。
那么服务器在负载最高时发生故障，这个概率必然是最高了。
2，技术值班人员较少，且最疲惫
加班熬夜已经是技术人员的家常便饭，但是生物规律依然有效。在值班人员较少并且疲惫时，故障不仅易被忽视，从而错过早期处理良机，而且处置应对效率不高，容易将后果和影响放大。
3，更新发布等人为因素较多
大部分软件应用系统，选择在晚间进行更新发布，新功能引起故障，或者由于操作失误。
4，展望：DevOps自动化运维
其实有更好的DevOps自动化运维，比如在早间业务量较低时定时自动发布，无需技术人员加班值守。
系统发生故障不可避免，但是影响可以降低。DevOps自动化运维，实时监控系统运行，及时响应处理故障。
5，DevOps实例
Facebook主程序发布策略，每天部署三次代码，每天选择的变更（cherry-picks）数量为 500 到 700，这样的发布频率，并且不影响到系统运行和用户，只有使用DevOps才能做到。
我是工作多年的Web应用架构师，陆续发布关于软件开发方面的文章，欢迎关注我，了解更多IT专业知识。
