运维是一份做不到满分的工作，追求平稳厌恶风险，但往往求而不得。原因很简单，运维的本质是“可控”，问题可控，风险可控，成本可控。如果觉得这些稀松平常，那一定是没被故障问题暴击过，目前国内的IT运维很多还处在紧急救援的队列中，不是他们不努力，实在是对手太强大。在IT架构中，IT运维监控是运维体系中重要的组成部分，作为运维的生命线，保障系统连续可用是首要原则，主要以监管控为实现手段。第一点：稳定性“可控
一、案例背景打工人的焦虑，已经延伸到在线文档了。近日，语雀P0级故障想必大家都有所体会，宕机近8小时，笔记、离线同步完全不可用。作为用户尤其担心我的文档资料是否会因此消失。这泼天的8小时，放眼互联网界也是相当炸裂的。从次日的故障处理通报可知，团队在收到运维监控系统报警后，定位故障根因来自于新的运维升级工具中的一个致命bug，该bug带来了一系列严重的影响。更深层次的问题在于高可用架构体系的设计、运
在IT转型驱动下，智慧医院建设已成为时代发展的必然趋势，在智慧医院建设中，运维管理扮演着重要角色，随着医院IT运维的管理目标、范围、对象及管理深度的改变，IT运维平台的建设正在向一体化、自动化、智能化、可视化等方向转变。LinkSLA智能运维解决方案围绕业务需求，提供涵盖SLA闭环管理，IT基础架构全链路监控，自动化巡检，主动安全等功能，满足用户对IT服务管理、资源管理的运维管理方案。01一、现状
CPU使用率监控很关键，综合反应系统的负载情况，是监控的重要指标之一。CPU的使用率，对业务系统性能有重要的影响，根据CPU使用率监控，可以对系统或应用进一步分析调优。4月25日22点，平台收到某县级医院HIS数据库服务器CPU使用率超出阈值报警，CPU使用率99%，远远高出预设的阈值 告警信息4月25日HIS数据库 CPU使用率超出阈值。事件持续1小时30分钟。处理过程 MO
一、背景随着数字化进程的加速，企业IT设备和系统越来越多，告警和流程中断风险也随之增加。每套系统和工具发出的警报，听起来像是一场喧嚣的聚会，各自谈论不同的话题。更糟糕的是，安全和运维团队正在逐渐丧失对告警的敏感度，甚至系统标出真正异常的事件，也可能因警报疲劳而被无视掉。在复杂的运维工作中，告警管理是运维工作至关重要的一步，不仅可以大大提高运维工作效率，还能帮助企业形成最佳事件管理流程，让业务系统运
数字化经济时代，IT架构复杂性越来越高，业务连续性成为很多行业或企业最核心的任务。业务连续性管理是一个不断提升的过程，围绕事件“发现-响应-定位处理-降低发生”的事件处理思路，结合平台化运维，助力业务快速提升。我们将具体事件从监控、调查、上报和响应几个环节来处理。即当平台监控发现异常，进行事件优先级分类，判断事件处理的紧迫性，分析事件影响造成破坏程度，然后进行事故调查与诊断，快速定位识别问题，联系
疫情短暂过去，一个乐观的共识正在蔓延：2023年的互联网，绝对不会比2022年更差。“降本”是过去一年许多公司的核心策略，营销大幅缩水、亏损业务大量撤裁，以及层出不穷的裁员消息。而2023年在可预期的经济复苏下，企业需要认真面对：能否、如何追回逝去的三年？一个精兵简政的组织，如何保持业务的战斗力？一、既要又要：降本 增效我们关注到，当企业业务发展的同时网络规模也会随之扩大，从最初的几台服务器到庞
对运维来说，保证业务系统的稳定、可用、安全是工作核心。盯系统、服务器或模块组件，查看日志、调整参数、性能调优、配置更改、响应需求等工作都是围绕这个目标而进行。随着企业规模不断扩大，服务器的日常管理也逐渐繁杂。通过人工频繁的更新、部署、管理，势必会耗费大量的时间，且容易产生操作上的疏漏。年初某三甲医院将IT资产接入公司平台进行监控。其中，有一台存储设备，接入平台后立刻生成告警，存储设备状态异常。大家
LinkSLA智能运维管家对主流数据库的监控，能够及时发现异常，快速响应，保障业务系统的稳定。平台通过对SQL Server数据库监控，帮助用户在数据库出现异常时事件处理。一、SQL Server数据库监控内容如下1 、数据库服务器基本性能监控。包括：服务器的CPU数量，内存大小，服务器在线时间，在线数据实例个数，离线数据实例个数和挂起的数据实例个数。2、监控数据库基本统计信息。比如实时用户连接数
LinkSLA与南京大学合作，将AI算法引入运维平台，将趋势性、周期性强的指标数据通过机器学习，实现异常检测、故障预测等功能。下面分享一个通过AI算法，对Oracle数据库故障预测的案例。在3月16日，MOC工程师接到某公司的Oracle数据库dbtime运维指标AI检测异常告警。查看告警详情，发现数据库的db time值与历史相同时间段的db time值区别比较大，并且 dbtime一直持续向上
LinkSLA 成本优化方案以可见、可控为特点，提供专业高效的运维支持，降本增效保持业务的最佳状态。
一、问题描述8月20日11点左右，接到某三甲医院信息科工程师反馈HIS、CIS明显卡顿。二、问题排查1、数据库服务器排查数据库服务器总内存172G, 分配到数据库内存150G，当前使用内存数量112G，内存使用＜分配内存，内存充足。数据库指标参数页预期寿命（Page Life Expectancy ）20秒左右，远低于应有的页面预期寿命11250s（150G/4G*300s=11250s）。一个小
一、现状&困境1、传统的监控方式，只关注IT基础架构的底层监控，而不是从业务系统的角度进行监控。2、关系梳理困难。业务系统关联的组件众多，要找出他们的对象及关联关系，是一个很复杂的梳理工作。3、排障修复效率低。运维发现故障，存在相互调用关系的业务可能也出现问题，排障效率大大降低，造成业务损失。故障导致的业务中断，对业务乃至企业产生负面影响，不仅给公司造成直接的损失，还可能影响企业未来发展。
IT系统架构是一个聚沙成塔的过程，随着业务规模的不断扩大升级，IT架构的复杂程度随之提升。在庞杂的IT架构下，应用系统紧密相连，一个指标变化，就可能引起一场告警风暴。如何行之有效地抑制告警风暴，高效处理告警问题，是运维必须面对的课题。避之不及的告警风暴冰冻三尺非一日之寒。PUA运维的从来不需要领导，告警风暴就能轻松拿捏住。如何抑制告警风暴？如何从海量告警信息中快速归因？如何快速定位告警问题？如何沉
11月27日晚间，滴滴因系统故障导致App服务异常登上热搜，不仅无法显示定位、无法打车，有司机的后台还显示收入超690亿。28日和29日，滴滴两次发文致歉，称初步确定事故起因是底层系统软件发生故障。相较于一些网友戏谑的“滴滴减‘猿’增效14%员工导致系统崩溃”，网传的“K8S版本升级错误，控制节点挂了，SRE工程师花了三个小时都未能解决”可能是滴滴系统大规模长时间故障的主要原因。一位业内专业人士指
近期，国内的互联网大厂接连爆发P0级事件，阿里云崩完滴滴崩，企业在追求效益的前提是业务的连续和稳定。如果发生故障不能快速恢复，引发业务中断，给企业带来的损失是巨大的，换言之，企业需要一套清晰、智能化的运维管理系统来帮助管理人员提高对整个IT系统的把控能力。运维的核心价值是保障业务系统的连续性。运维工程师可以通过IT运维软件实时监控全网设备的运行状况，网络链路的流量情况以及业务系统的运行情况。发现故
Redis简介Redis 是 C 语言开发的一个开源高性能键值对的内存数据库，可以用来做数据库、缓存、消息中间件等场景，是一种 NoSQL（not-only sql，非关系型数据库）的数据库。Redis特点优秀的性能，数据是存储在内存中，读写速度非常快，可支持并发10W QPS。单线程单进程，是线程安全的，采用 IO 多路复用可作为分布式锁支持十种数据类型支持数据持久化可以作为消息中间件使用，支持
11月27日晚间，一个普通的周一夜晚，对国内最大的网约车平台滴滴出行来说，却是一个充满挑战的时刻。平台突发的服务异常，让无数用户和司机陷入出行困境。#滴滴崩了#迅速登上社交媒体热搜榜首，显示公众对这一突发事件高度关注。用户反映，滴滴App出现异常，导致无法正常使用打车服务，司机在行驶途中遇到导航无法使用、地图无法加载等问题，造成一定程度的混乱和不便。“系统故障”，这是滴滴出行官方给出的解释。异常发
1、查找当前目录下所有以.tar结尾的文件然后移动到指定目录：find . -name “*.tar” -exec mv {}./backup/ ;❝注解：find –name 主要用于查找某个文件名字，-exec 、xargs 可以用来承接前面的结果，然后将要执行的动作，一般跟 find 在一起用的很多，find 使用我们可以延伸 -mtime 查找修改时间、-type 是指定对象类型（常见包括
1、POD启动异常、部分节点无法启动pod容器里管理应用pod是 K8s 中最小调度单元，POD里面的容器共享pod的空间、资源、网络、存储等。pod管理一个容器。pod管理多个容器。pod 出现异常的原因：资源过剩：大量POD在同一个物理节点，出现资源占用太多导致物理节点宕机。内存和CPU超标：pod中的应用出现内存泄露，导致pod内存迅速增多，pod kill 了影响节点正常提供服务。（解决办
原文链接：https://blog.gmem.cc/limit-disk-usage-for-podsPod 如何使用磁盘容器在运行期间会产生临时文件、日志。如果没有任何配额机制，则某些容器可能很快将磁盘写满，影响宿主机内核和所有应用。容器的临时存储，例如 emptyDir，位于目录/var/lib/kubelet/pods 下：/var/lib/kubelet/pods/ └── ac0810f
一切的变化来自于数据中心规模、复杂度、设备多样性的挑战，将运维平台的重要性推向历史高点。此外，基于业务连续性方面的考虑，分布式数据中心成为越来越多客户的选择。一、数据中心面临的挑战运维管理分散，缺乏统一的管理IT 建设“各自为政”，缺乏统一的管理规划，服务器、存储、网络等 IT 资源与虚拟化平台等信息分散，系统无法集中统一管理，无法实现全栈软硬件集中管理和自动维护，运维管理成本高。告警管理效率低管
医院运维，听起来平平无奇毫不惊艳，但其中的含金量，可不是“维持系统正常运行”就能总结的。毕竟医院对业务连续性的超高要求，让运维面对的问题都是暂时的，下一秒可能就有新问题需要发现解决。医疗信息化不断提高，各类设备、终端数量呈爆发式增长。IT运行环境日趋复杂，系统间关联逐渐加深，机房管理、系统监控...运维工作加量不加价。在保障信息系统高可用，稳定与安全之间，
一、Redis为什么变慢了1.Redis 真的变慢了吗？对 Redis 进行基准性能测试例如，我的机器配置比较低，当延迟为 2ms 时，我就认为 Redis 变慢了，但是如果你的硬件配置比较高，那么在你的运行环境下，可能延迟是 0.5ms 时就可以认为 Redis 变慢了。所以，你只有了解了你的 Redis 在生产环境服务器上的基准性能，才能进一步评估，当其延迟达到什么程度时，才认为 Redis
引言当提到命令行界面(CLI)时, 我们通常会想到一种强大而高效的方式来与计算机进行交互。在众多的 Shell 中最常用的就数 Bash 和 zsh 了，除此之外还有一颗闪耀的明星 Fish Shell，它以其现代化的设计和强大的特性而备受赞誉，成为许多开发人员和系统管理员钟爱的选择，正如官网宣传的 Finally, a command line shell for the 90s,
线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top 三连，然后依次jstack、jmap伺候，具体问题具体分析即可。CPU一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题
随着信息技术的飞速发展，企业对于IT系统的依赖程度日益加深。为保障IT系统的稳定运行，越来越多的企业选择智能运维管理软件，以全面高效的监控和管理系统和资产情况。 一、运维监控平台的重要性无监控，不运维。将资产并入监控系统，对每个资源节点的状态、性能进行实时监控。展示系统运行状态，高效应对规模庞大的基础设施，网络设备、服务器、存储、应用等，以业务视角监控系统健康度，系统视图展示各个资产运行的状态，业
一、云计算正在杀死运维吗？随着云计算的发展，企业上云已经成为一种趋势。企业上云的初衷是把复杂的IT基础设施交给云平台去管理，企业可以专注于业务与应用、从而降低企业IT运营成本，提高IT部门工作效率。因此有人会误以为，业务上云以后，运维就和企业没有关系了，只要业务系统可用就完事大吉了。然而实践并不如想的那么简单，而是给运维人员新的责任和机会，云平台的管理和运维依然需要专业人员进行监控，维护和故障排查
过线上 MySQL 维护经验的童鞋都知道，主从延迟往往是一个让人头疼不已的问题。不仅仅是其造成的潜在问题比较严重，而且主从延迟原因的定位尤其考量 DBA 的综合能力：既要熟悉复制的内部原理，又能解读主机层面的资源使用情况，甚至还要会分析 binlog。导致主从延迟的一个常见原因是，对于 binlog 中的事务，从库上只有一个 SQL 线程进行重放，而这些事务在主库中是并发写入的。就好比你多个人（多
11月12日晚间阿里云发生故障。“阿里云盘崩了” “淘宝又崩了” “闲鱼崩了” “钉钉崩了” 等话题相继登上热搜，阿里系诸多产品受到影响。阿里云对此公告称，2023年11月12日17:44起，阿里云监控发现云产品控制台访问及API调用出现异常，阿里云工程师正在紧急介入排查。18:54阿里云再度公告，经过工程师处理，杭州、北京等地域控制台已恢复，其他地域控制台服务逐步恢复中。这次故障使大部分阿里系产
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
