运维

本文作者：AIOps智能运维 作者简介 运小军 百度高级研发工程师 负责百度运维部大规模日志处理、海量事件数据存储相关设计研发工作，在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。 干货概览 本文主要介绍百度运维部监控架构团队在处理 大规模日志计算任务 时，为保证任务分配均匀性和稳定性，对原始 一致性哈希 算法进行改进。新算法在保持原始一致性哈希算法稳定性的同时，通过设置 不均衡因子 来控制分配的不均匀范围，达到负载分配均匀性与稳定性有效兼容。 一 业务场景 分布式系统中我们经常会面对如下业务场景： 计算系统每分钟有大量的定时任务需要及时调度并按时完成，单机在处理能力和时效性上都无法满足要求，需要将任务分配到大量Work节点上进行并行计算，我们如何均匀分配这些任务，并且在任务增减，Work节点退出/加入(伸缩能力)时保持任务分配的稳定性(不会引起大量任务迁移)。 分布式存储系统，海量数据被分片存储，那么如何让每个Data节点上分片更加均匀，并且在Data节点退出/加入时保持数据分片的稳定性。 高并发Web系统中，架构上几乎都是一个或多个反向代理服务器(如Nginx)来做七层负载均衡，后端使用应用服务器集群(如Tomcat)提供服务，这种架构具备水平伸缩能力，那么反向代理如何均匀分配请求，并且尽量保证请求Session粘性。 二 问题分析

本文作者：AIOps智能运维 作者简介 运小军 百度高级研发工程师 负责百度运维部大规模日志处理、海量事件数据存储相关设计研发工作，在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。 干货概览 本文主要介绍百度运维部监控架构团队在处理 大规模日志计算任务 时，为保证任务分配均匀性和稳定性，对原始 一致性哈希 算法进行改进。新算法在保持原始一致性哈希算法稳定性的同时，通过设置 不均衡因子 来控制分配的不均匀范围，达到负载分配均匀性与稳定性有效兼容。 一 业务场景 分布式系统中我们经常会面对如下业务场景： 计算系统每分钟有大量的定时任务需要及时调度并按时完成，单机在处理能力和时效性上都无法满足要求，需要将任务分配到大量Work节点上进行并行计算，我们如何均匀分配这些任务，并且在任务增减，Work节点退出/加入(伸缩能力)时保持任务分配的稳定性(不会引起大量任务迁移)。 分布式存储系统，海量数据被分片存储，那么如何让每个Data节点上分片更加均匀，并且在Data节点退出/加入时保持数据分片的稳定性。 高并发Web系统中，架构上几乎都是一个或多个反向代理服务器(如Nginx)来做七层负载均衡，后端使用应用服务器集群(如Tomcat)提供服务，这种架构具备水平伸缩能力，那么反向代理如何均匀分配请求，并且尽量保证请求Session粘性。 二 问题分析

本文作者：AIOps智能运维 作者简介 胖丁 百度云高级产品经理 负责百度云监控、Noah监控平台的产品设计和运营，致力于为百度云用户提供高效稳定的智能运维产品。 大家好，我是百度智能云的PM，今天与大家分享一下PM精（xi）彩（jing）的日常，我们是如何高效地与研发沟通的~ 为什么要沟通 首先，我们要问问自己，为啥要和研发工程师打交道。因为他们的新拖鞋很好看？ 当然不是。肯定是因为你希望研发按照你的预期完成某个任务，简而言之： Noah要更强！我要提需求！ 沟通的需求 生理需求： 医学研究人员发现，贫乏的人际沟通会危害冠状动脉的健康，其危害程度与抽烟、高血压、血脂肪过高、过度肥胖等一样严重，社交孤独者比活跃社交的人患感冒的几率高了4倍。 认同需求： 沟通是我们认识自己的唯一方法，我们对自我的认同源于我们和他人的互动。 社交需求： 沟通除了可以帮助我们诠释自我之外，也提供我们和他人之间重要的联结。 有效的人际沟通可以提升快乐感：研究超过200名大学生后发现，最快乐的10%都认为自己拥有丰富的社交生活。 实际需求： 沟通能够达成工具性目标。 工具性目标：让他人依照我们想要的去表现。如：让发型师稍微修剪刘海而不是剪成半长不短的狗啃刘海。 准备好论据 然后，我们需要问问自己，我的论据（PRD、原型图等）真的真的准备好了吗？请你指着自己写下的每一句话、画出来的每一个框框

本文作者：AIOps智能运维 在之前的系列文章《百度网络监控实战：NetRadar横空出世》中，我们介绍了百度内网质量监测平台NetRadar的原理和架构，其中， 判障算法 是内网监测系统的重要一环，今天我们将详细介绍在NetRadar中实际使用的一种判障算法——基于二项分布的网络判障算法。 业务场景 我们的内网监测系统 NetRadar 实时对百度内网连通性进行探测并根据探测数据判断是否存在网络故障。以探测机房A到机房B的连通性为例，如下图所示，首先从机房A和B中选择n个服务器对 ，机房A中的服务器 去探测机房B中的服务器 ，每次探测有 成功/失败 两种结果。在每个探测周期内，我们会收到n个探测数据，其中m个数据探测成功，(n-m)个数据探测失败。 理论上，在网络状态正常的情况下，m/n=100%。但实际中，由于服务器自身问题（发起探测的服务器负载过高、被探测的服务器重启等）以及一些偶然因素，少量的探测失败是不可避免的，所以需要设定一个判断网络是否故障的 阈值 。 阈值设定 在实际设定阈值的过程中，我们遇到两个问题： 单服务器故障导致产生探测数据的噪声 如前面所述，当服务器a探测服务器b时，如果服务器b自身故障（负载过高或者遇到机器重装、重启等）或遇到其他偶然因素，探测也可能失败，但并不能说明此时存在网络问题，这种情况我们称为 数据噪声 。 虽然单台服务器故障的概率不高

3 月，跳不动了？>>> 1 软件安装 （1）mercurial安装 # sudo apt-get install mercurial meld （2）apache安装 # sudo apt-get install apache2 libapache2-mod-wsgi （3）openldap安装 # sudo apt-get install slapd ldap-utils 2 软件配置 （1）假设软件仓库目录是/home/hg/repos(即所有的项目仓库都位于目录/home/hg/repos下) # sudo mkdir -p /home/hg/repos # sudo chown -R www-data:www-data /home/hg （2）仓库配置文件 sudo cp /usr/share/doc/mercurial/examples/hgweb.wsgi /home/hg # sudo vi /home/hg/hgweb.wsgi 修改为：config = "/var/hg/hgweb.config" # sudo chmod u+x /var/hg/hgweb.wsgi 新建hgweb.config，内容如下： 1 [collections] 2 /home/hg/repos = /home/hg/repos 3 [web] 4 allow_push=* 5

简介 capistrano是一个ruby语言写的代码自动部署工具。它的源代码在https://github.com/capistrano/capistrano。 作为一个自动部署工具，它的功能主要有： 1 可实现自动部署 2 通过ssh，可远程执行命令。 它与其他的自动部署工具不同之处有： 1和git /svn等版本控制工具亲和性高， 可实现自动代码拉取和回滚等功能。 推荐文档 https://github.com/stefanooldeman/capistrano-handbook/wiki https://github.com/capistrano/capistrano/wiki 如何安装capistrano sudo apt-get install ruby1.9.1 rubygems sudo gem install capistrano -v 2.5.15 其实capistrano3 已经发布了， 但是其文档当前比较少，只有其官网http://capistranorb.com/上有一点点可怜的入门教程。 而capistrano2的文档则相对比较全， 推荐这个wiki https://github.com/capistrano/capistrano/wiki 用gem安装的时候切换成国内的源会比较快 gem sources --remove http://rubygems

年关将至，又要写年终总结了，运维的工作庞杂又繁琐，一不小心工作总结就写成了流水账，让老板看不出你的成绩不说给再给老板留下不好的印象就更苦不堪言了...... 许多「聪明」的运维人员为了证明自己一年来对公司业务的贡献，提前一个月就开始去监控网站收集网站的周报、月报，并且从中挖掘出证明运维工作「有价值」的数据。目前国内外比较有名的监控网站有 NewRelic 、 AppDynamics 、 OneAPM-CT ，它们在功能上相差不多，我们以 OneAPM-CT 为例，看看都能挖到什么数据。 OneAPM-CT 的单页面/ Ping 监控 只需输入一个 URL/IP 地址即可。单页面监控可以看到 7 天内的 HTTP 错误、网络故障、 Timeout 错误，以及省份、运营商的性能、可用性指标。还可以详细看某个监控点的 DNS 时间、建立连接时间、后端响应时间、内容下载时间。 单页面监控还可以查看并下载日报表，周报表： Ping监控可以看到 7 天、 3 天、 1 天、 1 小时的平均响应时间、可用性、丢包率、加载时间。 API监控 可以看到 7 天的 code 应答错误、时间应答错误、内容匹配错误。 并且 CT 还会给您发周报哦，用这些数据做年度总结，岂不亮哉！ 有了 OneAPM-CT 帮您准备数据，您就能写出一份漂亮的年终总结、好好过年啦！ 本文转自 OneAPM 官方博客 来源：

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 关于 Ping Ping 是一个网络命令，主要是用于确定本地主机是否能与另一台主机交换（发送与接收）数据。根据返回的信息，就可以推断 TCP/IP 参数是否设置得正确以及运行是否正常。正常情况下，Ping 将返回若干个参数，丢失率为 0，当网络状态不佳或网络中断的情况下，Ping 操作将无法正常返回 TTL 参数（显示请求超时或其他 bug ）。 通过 Windows 平台的 ms-dos 可以简单执行 Ping 操作，然而这种操作只能简单测试网络是否正常联通，大体上排除网络访问层、网卡、MODEM 的输入输出线路、电缆和路由器等存在的故障，要想更进一步了解网站的连通速度和连线时间，获取连接错误的详细信息，还需要通过具体的监测工具。 超级Ping工具 是一套实现对多个主机网络状态的实时监测、监测结果分析、断网告警、网络状态上报等功能的工具，采用 ICMP 协议即 Ping 的方式来实现对主机网络状态的监测。具有以下几个特点：1、基于 ICMP 协议实现网络监测。2、支持连续监测和间隔监测两种网络监测模式。3、提供短信、邮件等多种网络异常告警方法。4、可同时监测多台主机。 Ping 监控的使用场景 要了解 Ping 监控的使用场景，我们就不得不介绍 Ping 监控 的几个指标。 可用性 可用性是在某个考察时间

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 对于运维团队而言，很多告警其实并不能帮助他们解决掉实际的问题，相反有时会加重多余的负担，这主要是因为大多数的告警并不具备足够的可执行性： 它们指出的问题压根儿不需要响应 它们缺少关键的信息，迫使你需要花费很长的时间去寻找更多的源头，用以来估量它们的紧迫性 过量的不可执行告警会造成 告警疲劳 ，浪费时间和资源，从而耽误你解决实质性的问题，可能这些已经在你身边正悄无声息地发生着： 你是否自动忽略收到的多余告警？ 你是否收到很多与你无关的告警？ 每当你收到告警时，是否为了获得你真正需要的信息而采取一系列常规的行动？ 如果有以上这样的情况，就能确定你是在遭受着告警疲劳，本篇将会列出四种常见的不可执行告警及其解决办法。 #### 1、无益的标题 问题：标题是告警的重要组成部分，因为它是你第一眼看到的东西。含糊不清的标题会迫使人们为了获取更多的信息而对告警主体进行不必要的挖掘，而当不同的告警使用相似的标题时，会使你感到更加沮丧、困惑，导致时间和精力上的浪费。 例子：在收到标题为「CPU LOAD 1.90」的告警后，你又收到一个标题为「CPU LOAD 1.80」的告警。这俩告警是否是关于同一个服务器的呢？负载1.80是否关键？这个问题会有什么影响？如果告警能提供解答而不是添加更多的问题，岂不是更好吗？ 改进措施

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 【编者按】本文作者为 Chris Riley，主要介绍告警疲劳的产生原因与对抗告警疲劳的8种方法。文章系国内 ITOM 管理平台 OneAPM 编译呈现。 各司其职、孤军作战非常不利于团队沟通，一旦发生重大事件，各个部门就很难掌握事件始末，这不仅降低了整个开发团队的沟通质量，而且对运维工作也造成了极大困扰，即告警疲劳。告警疲劳不仅会影响团队成员的工作情绪，而且会阻碍软件交付链的成长。 DevOps 的最大优势是清除沟通障碍并简化运维操作。通常，DevOps 团队有两种类别：一种是面向所有应用程序的集中式团队，另一种是面向每个应用程序或核心服务的去中心化团队。前者规模较大，但是比传统的NOC环境要小，而后者则是很小的团队。 DevOps 团队除了负责维护基础设施以外，有时还要管理发布过程，以及维持生产的正常运行。而最后这项工作是最伤脑经也最耗时的，一旦处理有误就会影响到整个环境。虽然没有人愿意值班待命，但我们还是得这样做，因为平均修复时间（MTTR）越短，问题响应越迅速，接下来的几天甚至几周里，大家的日子都会好过些——最重要的是它能维持业务的正常运转。 但是，一旦值班开始影响到团队情绪并占据运维团队大量的时间，就可能招致巨大的风险——集中式团队和去中心化团队很容易产生告警疲劳