运维

@郑昀 整理 标准做法一：OOM触发HeadpDump 目的： OOM发生时，输出堆栈快照文件，供研发人员分析。 在 JVM 中，如果98％的时间是用于 GC 且可用的 Heap size 不足2％的时候，将抛出 OOM 异常。 配置操作： Resin/Tomcat 配置文件里追加 -XX:+HeapDumpOnOutOfMemoryError ，当 OutOfMemoryException 错误发生时，会自动生成 Heap Dump 文件。 同时配置 -XX:HeapDumpPath 指定快照文件的实际路径。 日志分析： Heap Dump 文件的分析，可以 使用 Eclipse Memory Analyzer tool(MAT) 分析。 标准做法二：系统负载高触发ThreadDump 目的： 系统负载大于10时，调用 jstack 命令，输出 resin 线程快照，供研发人员分析。 配置操作： 一分钟扫描一次。如果系统的一分钟负载值（load1）大于10，或者80端口的连接数大于80时，进行打印。 日志分析： Thread Dump 文件的分析，可以 使用 Thread Dump Analyzer（TDA） 分析。 可选做法三：年老代使用率高触发HeapDump 目的： Java 工程的 OU/OC 到报警阈值 时，调用 jmap 命令，输出堆栈快照，供研发人员分析。 OC

作为底层码农，其实并不关心项目的优化！然而如今自己却不得不面对这样的问题，服务器的优化也许是最先优化的选择。 这里我就分享一下，虽然有些不足！但希望有所分享和帮助！ 一、服务器配置 先介绍一下服务器，在阿里云上买的包月服务器69个大洋，作为底层的码农还真的出血了。同时也在阿里云旗下的 万网 注册了 yi18.net 域名 CPU核数：1核 内存大小：512MB 系统名称： CentOS 6.3 64位 安全加固版 宽带：1M 服务器地址： www.yi18.net web服务器 :Tomcat8 linux 安装 tomcat 可以作为安装的产考，这里就不多说。本以为一切就绪，可以高高兴兴的享受自己的成就，但问题来了，Tomcat运行一段时间就宕机 ！于是不得不出现了下文。 首先Tomcat8还是alpha版本内测版本，但我还是没有怀疑是Tomcat的问题，所以不等不来配置Tomcat。 二、配置Tomcat自带的管理 Tomcat自己的Manager 配置文件conf/tomcat-users.xml 角色 manager-gui - 允许访问的HTML界面和状态页面 manager-script - 允许访问文本界面和状态页面 manager-jmx - 允许访问JMX代理和状态页 manager-status - 允许访问状态页面只 与用户 manager-gui

Cloud Insight 第13次新品发布会现在开始，首先非常感谢大家前来看我们的新功能发布会，下面我先给大家介绍一下新功能，之后有什么问题大家尽管问😊。 新功能 Cloud Insight 发布 4.4.0 版本，主要增加以及修复以下功能： 增加仪表盘标记线 增加仪表盘数据表现形式 增加仪表盘 rate 指标 增加 hostmap 无限分组功能 增加端口监控，进程监控 修复 Windows 平台显示问题 仪表盘是什么？ 天啊，互联网时代有人连这个都不知道，好吧，既然这样那我来解（an）释(li)一下，仪表盘就是汽车上显示转速表，里程表，机油，，，，balabala。😠不开玩笑，我们是一个严肃的产品，仪表盘其实是将你关心的所有数据用图表这种更直观的形势展现出来的一种表现形式。 再说简单点，就是你今天想统计一下敲了多少下键盘，点击了多少下鼠标，看下面这个图就明白啦！ 这个仪表盘和运维有什么关系？ 好问题，这个问题问的很有水平嘛！举一个最简单的场景：5 台 MySQL 数据库平常 5000 连接，如果突然间整体访问量剧增，这个时候你需要知道每台服务器数据库访问情况，整体访问情况，整体增长情况。 用仪表盘可以设2个表盘，一个是显示5台服务器各自访问连接情况，一个显示总体访问连接情况，当然要想更全面的确认访问量剧增是出现攻击还是真的有很多用户访问，还要加上其他数据库操作的监控指标。

VNC (Virtual Network Computing)是虚拟网络计算机的缩写。VNC 是一款优秀的远程控制工具软件，是基于UNIX和Linux操作系统的免费的开源软件（也可以支持Windows等操作系统），远程控制能力强大，高效实用，其性能可以和 Windows 和 MAC 中的任何远程控制软件媲美。本文简单介绍在Ubuntu的Linux发行版下VNC服务的配置和使用。 假设系统信息如下： 服务端：Ubuntu 11.04 \n \l 客户端：Ubuntu 11.04 \n \l 其他系统中配置的过程和原理大致类似。 1,服务端 ======================= (1)安装vnc服务程序 #sudo apt-get install vnc4server 这里，有可能还需要安装"vnc4-common"。 (2)设置连接vnc服务的密码 #vncpasswd 这样会提示你输入密码，客户通过这个密码来进行连接，这里密码假设为12345678。 (3)配置启动桌面 *配置方法1： #cp /etc/X11/Xsession ~/.vnc/xstartup 这里配置的是客户连接之后，在客户端显示什么样的图形桌面。这里直接使用vnc服务器所在系统的桌面环境配置了。如果不进行配置，那么客户端登陆的时候就只能启动默认的窗口管理器非常简单不好用。 *配置方法2： #vim ~

DevOps ，是开发（Development）和运维（Operations）的组合，代表一种文化、运动或实践，旨在促进软件交付和基础设施变更软件开发人员（Dev）和 IT 运维技术人员（Ops）之间的合作和沟通。它的目的是构建一种文化和环境使构建，测试，发布软件更加快捷，频繁和可靠。 现在2016年 DevOps 逐渐成为主流，来自云端、移动和社会等基本需求的驱动将促使越来越多的公司认识到采用 DevOps 最佳实践可能获得的文化、性能和经济效益。 精简灵活的公司已经在过去几年感受到了 DevOps 和持续交付带来的好处，而成熟的大企业也意识到了它们的价值，开始进行文化转型。但是这些企业对待 DevOps 的态度相当谨慎。所以预计在2016年，在广泛使用 DevOps 之前，企业会在非关键的新 IT 项目中进行 DevOps 测试实践，这将涉及进程、自动化、协作和工具等方面，其间的协同合作也极大的提升了工作效率。 通过查看 IT Central Station 中关于 DevOps 解决方案的真实用户评论，可以发现研究和购买 DevOps 解决方案的用户已经发生了变化。之前，许多评论都是 DevOps 经理和发布经理写的。现在则会看到很多 IT 行业的其他职能单位---架构师、客户服务经理、中间软件专家、网络工程师及其他人写的关于 DevOps 工具的评论数量正在增长

作为新人第一次在这里写点东西，将工作中的部分记录下来，希望能和各位大牛交流学习下。很多操作来源于网络，当然也少不了同事的帮助，在此感谢这些无私奉献的大牛们，通过自己的实践操作现将操作和心得做下总结希望各位大牛多多意见，批评。 做运维的朋友都免不了需要给大批量的服务器安装系统。我们通常分为两种情况一种是在架设机房的时候有大量的服务器上架；另一种是小批量的从本地发往机房，包括服务器替换和小批量的机房扩建情况。 下面谈谈我对这两种情况的看法吧，这两种情况无疑都需要给服务器安装系统（谁特么都知道，要你说。。），当然这也许稍微有点不同，对于第一种面对大量服务器的情况，如果我们一台一台手动安装这个效率...唉，当然不说你也能知道。一般我们去到IDC机房的处理方法是，将所有服务器上架，按设计的网络拓扑图布线连通网络，配置好需要的RAID和网络参数，接下来我们就会将我们作为安装系统的母鸡（机），也就是配置了PXE和WDS的本本连接进这些需要安装的服务器所在的局域网，这也就是本文将要提到的重点。 我们来说说另外一种情况吧，一般的互联网公司都会有自己的装配测试间，用来测试新的机器性能和测试一些解决问题的新方法，当然也会用来安装系统，和测试不通系统在机器上得运行情况。当然我们这里只谈谈安装系统的部分（毕竟我也只是个小小鸟而已，多的也还需要不断学习）。在公司给小批量的机器装系统，如果很少

[编者按]本文作者为陈伯龙，云告警平台 OneAlert 创始人，著《云计算与 OpenStack 》，在IT运营管理、云计算方面从业10多年。 ##正文 互联网技术的发展，离不开运维支撑工作，没有零bug的程序，没有不出问题的系统，问题故障不可怕，可怕的是没能有序的处理： 突发紧急事件太多，疲于应付，团队士气低下，效率不高。 重要事情淹没在大量事件中，没有有序跟进处理，会引发严重业务影响。 如何有效处理紧急事件驱动的工作，成为（特别是运维主管）运维工作的关键。我接触了大量的各类型公司运维，从初创、中小、大型公司，总结和分享一些大多公司通用的on-call机制，帮助有序的处理紧急事件： 监控告警事件集中化。 建立多层次和职责划分的支撑团队。 通知到位和及时响应。 告警风暴关联合并。 事件单记录和团队协作。 基本上都是围绕人、流程、工具三方面进行，参考了ITIL的管理思路，大家感兴趣也可以参考下，特别是其中的ITIL V3的运营管理。 ##监控告警集中化 大多公司都用了zabbix和nagios、open-falcon等监控工具，对硬件、网络、应用进行监控。可能会存在监控分散问题： 环境比较复杂的时候，可能会用多个工具，如cacti监控网络，zabbix监控应用和服务器。 如果有多个异地数据中心时，可能需要部署多个zabbix和工具。 部分关键业务，需要单独的开发监控脚本

前不久，我们讨论了运维不容错过的 4个关键指标 ，其中平均解决时间（MTTR）被认为是衡量业务的最佳标准，随后也分析了「 告警等级 」对MTTR的重要性。 ###正确看待 MTTR MTTR 为从故障发生到故障修复所经历的时间。总故障时间是关于告警事件数量与各告警事件时长的函数。经过仔细地探讨这两项因素及其优先级，结合具体情况，总结以下策略用来缩短MTTR： #### 1）加快工作速度 = 然并卵 如果想通过加快工作速度降低 MTTR，理论上是完美的，但是骨感的现实根本不按我们的剧本走！为了对 MTTR 进行持续的、可衡量的改进，应该对故障事件进行深入的调查，分析事件的复杂程度及重要程度，然后从人与系统的协作上，实现对流程进行优化。 #### 2）检验告警响应时间 一旦事件发生，「MTTR」时钟便开始计时。通过调整通知流程，或许就能速战速决。下图为常见故障处理过程： 还不够直观？数据来说话。 OneAlert 一个月的告警数据显示：平均响应时间为 2.8 分钟；平均解决时间为 27 分钟。（不要问我为什么你们的响应时间要好几个小时！） 如果你的响应时间较长，建议检查一下团队值班响应机制，告警是否可有效传达给了正确的人？如果一线排版人员无响应，告警能否自动升级？升级时间阈值是多少？通过设定接近平均响应时间的适当期望值和目标，能确保所有成员尽快对告警作出响应。 #### 3

当然不是指像上图那样一边开着车听着歌，握着男/女朋友的手，一边查看告警邮件的时候要慢一点。原因大家都懂的，我就不拆了（因为你们都是单身狗啊！单身狗啊！单身狗啊！）。这里要说的是，如果你们选择了用 OneAlert 来接收告警邮件，查看的时候可一定要慢一点，慢一点，再慢一点啊！为啥呢？ ######在你还没有用 OneAlert 的时候…… 我们责任心爆棚的运维菌们，为了让用户有更好的体验，为了系统不挂，为了不被领导骂，为了升职加薪，为了迎娶白富美……通常会使用各种各样的监控工具来对系统性能进行全方位的监控，比如功能强大又免费的 Nagios ， Zabbix 。你想用它们来监测 CPU 使用率，磁盘利用率，网卡吞吐量等等。你设定好了阈值，想让它们在故障发生时给你发封邮件通知一下。然后，噩梦开始了…… 镜头一：初入职场的运维菌小张负责维护公司里的一台服务器。小张对她呵护备至，第一天就配置好了 Nagios，希望能第一时间知道她哪不舒服了。某天半夜1点，她终于宕机了。告警邮件如约而至，然而早上7点起床睁眼抓起手机的小张却当场石化了。新邮件通知设置成了静音的他一共收到了：1台服务器x1条进程x1次/分钟发出告警x6小时x60分钟=360封邮件……小张草草扫了一眼，内容实在懒得看，快速点击全部勾选，一页一页地直接全部删除掉

没有天下第一的武功，但如果你的速度够快（比如接近光速），必然无敌。 11 月 20 日晚，深圳龙岗爱联爱新小区里的 54 辆私家车被刮花，等到车主们调取监控录像后才发现，竟是 4 名年龄都不超过 10 岁的「熊孩子」拿着石块把小区里的车辆当成了画画的面板。目前，爱联派出所已介入调查，熊孩子究竟是谁仍在核查中。 由刮车事件引发的联想...... 「我们觉得这件事主要还是家长监管和平时教育不到位，并且事发已经好几天了，也没有人主动出来承担责任。」车主李先生表示，小区里过半车俩被刮花，修理费用加起来已超过了15万元，而且由于是人为损坏，保险公司不会理赔，大家都希望这件事能有个结果。「如果这次不弄清楚，担心以后还会出现类似的情况。」事发后业主们纷纷讨要说法。 事虽小，但出现的问题很发人深思：监管、监控不到位，导致群体悲剧上演。如果能在孩子身上放一个类似监控器的东西，当孩子刮第一辆宝马车或者将要做出刮车的这个动作时就可以受到制止，又或者车辆内有足够强大的告警系统，当受到侵害时就能够第一时间传达给车主或者鸣响报警，那结果是不是压根儿就不会这么严重呢？！ 说多了，读者该嘲笑我异想天开了。但今天我想说的是，随着企业业务发展的深入，IT 系统也日益复杂。公有云、私有云大规模应用，网络、服务器、软件应用系统之间错综的关联关系，使得 IT 管理和运维人员面对最终用户反映的应用不稳定、系统中断等问题时