欢迎光临
免费的PDF电子书下载网站

网站运维技术与实践(大型网站一线运维技巧与经验总结,全面解析运维相关技术) PDF下载

编辑推荐

  •   资深一线运维专家诚意之作,总结多年实践经验,深入浅出,内容涵盖运维工作各方各面。
  •   百度、新浪、人人、音悦台等多名技术经理、高级工程师联名力荐。
  •   《网站运维技术与实践》深入阐述了运维工作所涉及的监测调优、日志分析、集群规划、自动化部署、存数和数据库等各方面的技术要点,引入了开源产品的实践经验,包含了对自动化运维和DevOps等技术形态的大量思考,旨在帮助运维人员“懒惰、急躁和傲慢”(程序员的三大美德)地完成网站运维工作

推荐购买:

技术管理之巅——如何从零打造高质效互联网技术团队?

玩转电商系统:深入剖析智慧电商平台

大型分布式网站架构设计与实践

Linux运维之道

 ;

内容简介

  网站运维工作,一向以内容繁杂、覆盖面广著称。《网站运维技术与实践》选取日常工作涉及的监测调优、日志分析、集群规划、自动化部署、存储和数据库等方面,力图深入阐述各项工作的技术要点及协议原理,并介绍相关开源产品的实践经验。在技术之外,作者也分享了一些关于高效工作及个人成长方面的心得。

  《网站运维技术与实践》适合Linux系统管理员、中大型网站运维工程师及技术负责人、DevOps爱好者阅读。同时也适于刚踏上或有兴趣踏上运维岗位的年轻朋友,了解运维职业的工作和发展。

作者简介

  饶琛琳——“资深运维”,先后在世纪互联云快线和中华网负责运维工作,热爱CDN并乐于尝试一切可以给互联网用户带来便利和优质体验的技术。——“DevOps”,现任人人公司网络运营部高级研发工程师。专注自动化运维平台的构建,活跃于Puppet和Logstash开源社区。——“死理性摩羯座”,比特币大潮中依然坚持要写程序实践证券投资分析原理和时间序列数据预警原理。——“Larry Wall教徒”,推崇“懒惰、急躁和傲慢”三大程序员美德,并时时运用于运维工作中。同时热衷于推广以perltidy、Moo、AnyEvent和Plack为代表的新一代Perl编程,参与组织了Perl中国用户2013年度大会。

网站运维技术与实践(大型网站一线运维技巧与经验总结,全面解析运维相关技术) PDF下载

目录

第1 章 服务器监测1.1 理解监测的意义1.2 通过命令了解系统的性能概况1.2.1 ifconfig1.2.2 w1.2.3 df1.2.4 ps1.2.5 vmstat1.2.6 netstat1.2.7 iostat1.3 其他常用工具1.3.1 sar1.3.2 dstat1.3.3 mtr1.3.4 IPtraf1.3.5 TcpDump1.3.6 Wireshark1.3.7 strace1.3.8 stap1.4 SmokePing 网络质量监测1.4.1 原理1.4.2 配置说明1.4.3 报警1.4.4 WebUI1.5 Nagios 分布式监测1.5.1 架构原理1.5.2 Plugin 编写1.5.3 SNMP 网络监控.1.5.4 Gearman 分布式1.5.5 OMD 介绍第2 章 产品访问监测2.1 关注产品比服务器更重要2.2 网站监测的明星指标2.2.1 可用性2.2.2 响应时间2.2.3 首屏响应时间2.3 网页浏览过程简介2.3.1 解析域名2.3.2 连接服务器2.3.3 发送请求2.3.4 等待响应2.3.5 传输响应内容2.3.6 浏览器渲染处理2.3.7 并发请求2.4 浏览器网络监测与分析2.4.1 Firebug .2.4.2 Chrome 开发人员工具2.4.3 HttpWatch2.4.4 rvictl 接口监控IOS 设备2.4.5 HAR 格式2.5 第三方监测2.5.1 基调网络2.5.2 监控宝2.6 简单定制JS 监测2.6.1 页面内嵌JS2.6.2 Nginx 日志记录和存储2.6.3 数据展示2.7 Boomerang第3 章 数据采集、传输与过滤3.1 采集点的取舍3.1.1 服务器数据3.1.2 访问日志3.1.3 系统日志Syslog3.2 收集传输3.2.1 Rsyslog3.2.2 message queue3.2.3 RPC3.2.4 Gearman3.3 日志收集系统框架3.3.1 Flume-ng3.3.2 logstash第4 章 数据分析与报警4.1 时间序列存储4.1.1 RRDtool(Round-RobinDatabase Tool)4.1.2 Graphite4.1.3 OpenTSDB4.2 全文搜索引擎ElasticSearch4.2.1 简介4.2.2 安装4.2.3 集群4.2.4 基础查询4.2.5 优化4.2.6 时间序列统计示例4.3 数据可视化4.3.1 RRDtool4.3.2 Gnuplot4.3.3 AmCharts4.3.4 其他绘图库4.4 报警4.4.1 SendEmail4.4.2 WebSocket4.4.3 手机推送4.4.4 分级和归并第5 章 测试评估5.1 服务器性能测试5.1.1 IOzone5.1.2 Netperf5.1.3 pktgen5.1.4 sysbench5.2 应用性能测试5.2.1 http_load5.2.2 AB5.2.3 weighttp5.3 分布式测试环境5.3.1 AutoBench5.3.2 TCPCopy第6 章 集群架构规划6.1 IDC 的规划和选择6.1.1 网站性质决定基础面6.1.2 IDC 厂商服务质量6.1.3 BGP 真伪的验证6.2 CDN 规划6.2.1 CDN 原理6.2.2 DNS 原理6.2.3 DNS 查询结构实现6.2.4 DNS 调度6.2.5 其他调度方法概述6.2.6 动态加速概述6.3 缓存设计6.3.1 HTTP Header 对缓存的影响6.3.2 Squid 的LM-factor 过期算法6.3.3 squid 的ACL 控制6.3.4 Squid 的aufs/coss缓存引擎6.3.5 squidclient 的运用6.3.6 使用SSD 提高性能6.4 本地负载均衡6.4.1 LVS 负载均衡原理6.4.2 keepalived 与VRRP 高可用原理6.4.3 Nginx 的upstream6.4.4 squid 的cache_peer第7 章 弹性控制和部署7.1 配置集成的思想7.1.1 抽象的集群管理7.1.2 通用模式设计7.2 操作系统部署KickStart7.2.1 基本原理7.2.2 配置安装7.3 应用部署与配置管理7.3.1 SSH::Batch7.3.2 Puppet7.4 搭建私有软件仓库7.4.1 使用spec 文件构建RPM 包7.4.2 命令行打包工具FPM7.4.3 yum 私有仓库7.5 随时控制成本7.5.1 CGroup 配置简介7.5.2 内存限制7.5.3 CPU 共享限制7.5.4 CPU 绑定限制7.5.5 块设备读写限制7.5.6 配合TC 完成网络限速7.6 关于云计算第8 章 分布式文件系统8.1 NFS8.1.1 原理8.1.2 服务器端配置和优缺点8.1.3 客户端参数优化8.1.4 丢包与网络参数优化8.2 简单易用的FUSE 协议8.3 MogileFS8.3.1 GFS 介绍8.3.2 MogileFS 介绍8.3.3 MogileFS 内部原理8.3.4 安装和配置8.3.5 客户端配置和使用第9 章 数据库9.1 MySQL 必知必会9.1.1 常见SQL9.1.2 导入导出9.1.3 简单配置调优9.2 慢查询分析工具mysqlsla9.2.1 使用9.2.2 结果分析9.3 Percona 工具集9.3.1 备份恢复工具XtraBackup9.3.2 在线运维工具箱Toolkit9.3.3 监控插件集9.4 监控工具9.4.1 mytop 和innotop9.4.2 orzdba9.5 MySQL 集群9.5.1 MySQL 复制原理9.5.2 MHA 原理9.5.3 MHA 安装使用第10 章 备份与同步技术10.1 rsync10.1.1 原理10.1.2 常见运用10.2 inotify 和sersync 工具10.2.1 inotify 概述和示例10.2.2 sersync 介绍10.2.3 sersync 配置用例10.3 Netcat10.3.1 文件传输10.3.2 端口扫描10.3.3 远程控制10.4 P2P 传输网络10.4.1 P2P 协议概述10.4.2 BitTorrent 概述10.4.3 murder 部署和运用第11 章 运维制度化与自管理11.1 运维制度化11.1.1 运维为什么要制度化11.1.2 运维如何制度化11.1.3 SLA(Service Level Agreement)协议11.1.4 故障处理的五问法11.1.5 知识库11.1.6 流程跟踪的Tracker系统11.2 自管理11.2.1 时间管理11.2.2 思维导图11.2.3 Git 管理和应用11.2.4 交流与活动

媒体评论

最早跟年年(饶琛琳)的认识和沟通一直都是在微博和他的博客上,他是我很尊重的技术思考者和实践者。运维工作有时会被认为是乏味且缺少技术含量的,因缺乏对必要知识的提纲挈领般的引导,很多运维同学难以快速地掌握运维的门道,而只能在忙碌和无奈中徘徊。感谢年年同学辛苦力作,将他广博的运维知识和对技术的深度思考、实践总结出来,深入浅出地带我们走进运维的世界。
王春生 (@平凡的香草)
新浪研发中心技术保障部高级技术经理
中大型网站的运维工作牵扯较多且细节繁杂,需从一定高度来解决应对。弄清问题本质、根据相关技术原理探寻适合的方案、设计开发对应的平台系统和自动化工具,是资深运维人员的必备技能和目标追求。边喝着咖啡边把问题解决了或者由系统工具自动发现问题并修复,是理想的并且努力可以达到的场景。琛琳在自动化运维相关领域实战经验丰富,成绩斐然,本书是他多年工作的心血结晶,其中大量的代码、配置片段和软件方案给想进一步提高的运维工程师提出了一些思想思考或者说指引了前进方向。推荐有志青年仔细学习研究本书,共同把自动化运维推向一个新高度。
张秀岭 (windtear)
人人公司高级技术专家
读完这本书,惊叹于作者陈子(饶琛琳)渊博的知识和无私的分享精神。这本书是浩瀚的互联网技术知识海洋里的一张地图,每一章都像是一块大陆,虽不能从地图上看尽大陆的美丽风光,却能在一张纸上教会我们往哪里走可以到达目的地。更加难能可贵的是,这本书介绍的思想、软件和产品都是*的,有着非常强的时效性和实用性。
斯文(@小斯chinatopsquid)
百度系统部CDN资深研发工程师
作者在CDN和大中型网站运维方面有着非常丰富的经验。本书成体系地讲解了运维工作中能使用到的方方面面,其中很多技术细节和方案是其他运维类技术书籍中很少提到的,看得出来都是作者多年实际经验的总结,非常值得相关的用户仔细研读。书中CDN 方面的一些应用,更是目前市面上的技术书籍中难能可贵的资料,值得研究和深入了解。从全书整体也可以看出作者出身于专业的 CDN 公司,因为像网站性能测试、日志收集处理、存储系统之类都是专业性非常强的。全书涉及知识点非常丰富,任何一个方面拿出来都可以单独出版成书。
扶凯
音悦台系统运营总监

前沿

运维是一个古老但愈发新奇的职位。在不同时代、不同公司,都有不同的称呼。在万维网到来之前漫长的几十年中,运维工作大都由系统本身的开发人员来完成,他们很自豪地给自己加上了系统管理者(SystemAdministrator)的头衔。随着万维网的出现和发展,计算机系统管理者中也就出现了专注于网站管理的人群,这些人自称为网站管理者,至今我们依然可以在一些历史悠久的软件(比如Apache、Squid)的配置中,看到专门的指令来设定这个身份。与此同时,在互联网的另一端(接入端)——为普及上网而大量出现的网吧和网城中,另一批专注于网络接入、局域网共享和桌面应用管理的人群,则被称为“网吧管理员”。接入端牢牢占据了绝大多数人对互联网的第一印象,并将他们所能触及的方面认定为互联网从业人员的全部,即软件开发者和网络管理者。
  毫不讳言,笔者在五年前(大学毕业时),同样以这种眼光看待自己“很熟悉”的这个互联网。
  那么,除去接入端的网管,在互联网的另一端的管理者们到底是什么状态呢?
  先说看得见的一面:每次当你发现网页变样了,这说明网站管理者完成了一次应用发布;每次你投诉访问有问题并附上截图,这意味着网站管理者要开始一次故障排查和修复;每次你觉得比上次访问快一点了,这说明网站管理者已经悄悄结束了一次后台优化……
  再说看不见的一面:管理者尽力为你提供优质的访问体验,也带来指数级增长的新访问者。一百万、一千万乃至更多,大家的访问体验都要一样好,数据都要一样可靠,甚至业大招贼后还要保护大家的信息不被窃取……这些问题的背后,都是网站管理者的工作。
  正是由于网站管理者与访问者之间的频繁交流,以及网站访问数据对业务发展的支撑,慢慢地将管理者的职责从系统维护扩展到了运营相关的广泛领域,最终合二为一成为了“运维”,而这也是现代的专职的“网站运维”与“古代的”模糊化的“系统管理员”最重要的区别。在业内公推为经典著作的WebOperations一书中,甚至专门有第8章“CommunityManagementandWebOperations”来讲述运维和用户交流、社区管理相关的内容。
  从上一代互联网巨头引申出网站运维这个独立的职位到现在,运维的职能依然在不断细化和变化——网络运维、系统运维、应用运维、数据库运维,甚至更细分的CDN运维和业务变更运维,都有专门的人员和团队来负责。运维团队甚至不再仅仅是网站服务的支持方,还越来越以网站内部的技术需求方的角色出现,进行广泛而细心的考察,采取更激进的方法,从而提升网站的单位成本效益。
  从大概一两年前开始,另一个新的概念“敏捷运维”(DevOps)跟随云计算的浪潮出现。从思想和理论上,目前对其依然没有准确的定义,但从技术实质上,无非是在保证产品质量和访问性能的前提下提高产品发布的频率,“自动化一切可自动化的工作”加上“充分了解业务流程”——而这本来就是一个优秀的运维人员应该去实现的事情!
  了解业务流程是一件取决于个人偏好和公司文化的事情,虽然笔者在过去的工作经历中见过不少比相应的开发负责人还了解业务的老运维人员,但是这方面确实很难说出太多可以循序渐进的道理,还是让我们先掌握那些可以帮助我们“Laziness,ImpatienceandHubris”(程序员的三大美德——懒惰、急躁和傲慢——出自LarryWall的ProgrammingPerl)地完成网站运维工作的技术吧!
  饶琛琳

免费在线读

  11.1.4 故障处理的五问法
故障是运维工作中必然会遇到,而且可能每天都会遇到的事情。故障处理是运维人员最主要的职责之一。对整个网站系统的故障处理的能力,也是考验和衡量一个运维团队能力的重要指标。
如何形成一套有效的故障处理流程,提升个人以及团队的排障能力呢?这里笔者推荐“五问法”。
“五问法”是丰田公司最早发明的用来研讨未知问题的因果关系的迭代技术,属于其“问题解决流程七步骤”中的第四步。由于这一步是全流程中最有特点的一步,通常也会用它来代指整个流程。
注:在ITIL中,故障和问题其实是侧重不同的两个事情,即trouble和bug的区别。但考虑到运维中trouble除非是操作失误,大多会升级到bug,这里不做区分。
整个流程分为三个阶段,即了解情况、调查原因和提出解决方案。
1.第一阶段
◎ 第一步:界定问题范畴。是新问题还是老问题重复出现?是大故障还是小故障?以及影响多大,重要性多高等。
◎ 第二步:找出真正的问题。这一步不是问问题原因,而是从各种表象中理清头绪,类似于去噪的作用。
◎ 第三步:找出问题的原因点(Point Of Cause)。通常通过时间人物地点事件几大要素来定位。有时候就直接找到了原因,但大多数时候原因还值得深入挖掘。
2.第二阶段
◎ 第四步:五个为什么。
所谓“五个为什么”,就是我们通常所说的“打破砂锅问到底”,一定要找出根本原因(Root Cause)。丰田曾经在演讲中举过下面这个例子。
碰到一个问题:汽车无法启动了。
为什么?——电池电量耗尽。(第一问)
为什么?——交流发电机不工作。(第二问)
为什么?——交流发电机皮带断裂。(第三问)
为什么?——交流发电机皮带使用寿命已经到了但是没有换新的。(第四问)
为什么?——没有按照建议进行定期维护保养。(第五问)
当然并不一定是要勉强凑出五个,或者压缩到五个。目的只是为了通过递进的五个为什么,追究出问题的本质原因。比如在上例中,后人认为没有定期保养依然是可以追究原因的,于是又添加了第六问。
为什么?——汽车本身太老,已经没有对应型号的发电机皮带可换了(附加第六问)
在运维工作中,人们通常遵循一个基本原则即“尽快恢复服务”。在这个原则下,如果不提醒自己多问几个为什么,运维工作就很容易陷入枯燥低水平的重复劳动中——比如玩笑中常说的“重启绝招”。
人们常说运维最难的就是积累经验,而最难得的就是有一套自己的排障思路。这些,正是靠对每次故障、每个问题都用五问法死追到底,最终才能做到熟能生巧。
3.第三阶段
◎ 第五步:针对根本原因(Root Cause)的解决办法。有多种办法时要分别评估效益。比如上例中,如果按照第六问的结果,解决办法可以是购买新汽车,也可以是干脆坐地铁。
◎ 第六步:检验评估解决办法是否有效,并作出相应修正。
◎ 第七步:将本次问题解决流程标准化。
这个阶段也就是处理总结阶段。其中最关键的问题就是要将处理流程标准化。运维有一句话叫做“不要做重复的事情”,这不单可以用作自动化工具的开发动力,同样也是总结操作流程的目的。
最后,如果将整个流程固定化,就可以成为故障处理的格式化报告。下附一例,如表11-1所示。
11.2 自管理
运维本身的职责就是管理,那什么又是“自管理”呢?笔者认为自管理分为两部分:一是运维团队对内工作、团队建设方面的管理;二是运维人员对自身知识体系、工作技能和时间安排方面的管理。
11.2.1 时间管理
首先来说说时间管理,大家都知道运维工作的一大特点就是要724小时待命。不过待命本身并不是一个占用时间的状态,所以对于正常的8小时工作时间,还是需要进行合理安排,有效地利用时间以达到最好的效果。这里介绍两个最简单的时间管理规则——四象限法和番茄法。时间管理本身是一个值得专门研究的课题,这里只选取这两个规则的理由是:即便不知道这两个规则的人,在工作过程中,也会不自觉地趋向于这两个规则中体现的一些特点。介绍这些规则,并不是想要让读者改变自己的习惯,而只是点明一些原本个人的行动可以更规范、更明确地固定住,长期地保持下去以取得效果。
11.2.1.1 四象限工作法
不单单运维,世上绝大多数工作都可以归类为四种类型,也就是所谓的四个象限。
◎ 第一象限代表重要也很紧急的工作;
◎ 第二象限代表重要但不紧急的工作;
◎ 第三象限代表紧急但不重要工作;
◎ 第四象限代表不重要也不紧急的工作。
第一和第四象限的安排肯定都没问题,比较让人迷惑的是第二和第三象限的时间安排。事实上,普通人和高效人士的时间安排差别就体现在这里。高效人士总是优先在做重要但不紧急的事情,所以才总是显得那么游刃有余。图11-19是两种人群的四象限时间安排统计对比。
那么如何找到把更多的时间用在做更重要的事情上面的方法呢?
美国效率专家艾维利为伯利恒钢铁总裁提出的“六点优先工作制”的方法,就是针对这个问题的。六点优先工作制的主要思路如下。
首先,在每天开始工作之前,提前列出当天准备做的全部计划,并且按事情的重要性,依次标出其中最重要的六件。
开始工作后,全力以赴去做排名第一的最重要的那件事情,直到完成,期间绝不去想其他计划。然后再全力以赴排名第二的事情,以此类推。
一般来说,如果一天能完成最重要的前6件事情,可以说这一天的工作效率就足够了。
这时候有的人可能会提出,作为运维人员,在完成一件“自认为”很重要的工作时,几乎肯定会被别的突发事情打断,断断续续之下,工作质量很难达标,最后还是“缝缝补补又三年”的勉强维持。
笔者建议是,模仿“封闭开发”的做法,强制每天固定拿出一段时间来当做“封闭运维”。一方面可以静下心来集中做一些重要而不紧急的工作,另一方面也可以静下心来自我反思并调整自己第二天的时间安排。封闭上一段时间,当你第二象限占时比例慢慢变高后,就会发现事实上那些“不重要而紧急的工作”也随着你的高效而变少了。这正是运维自动化目的从另一层面的反应。

网站运维技术与实践(大型网站一线运维技巧与经验总结,全面解析运维相关技术) pdf下载声明

本pdf资料下载仅供个人学习和研究使用,不能用于商业用途,请在下载后24小时内删除。如果喜欢,请购买正版

pdf下载地址

版权归出版社和作者所有,下载链接已删除。如果喜欢,请购买正版!

链接地址:网站运维技术与实践(大型网站一线运维技巧与经验总结,全面解析运维相关技术)