The overwhelming majority of a software system’s lifespan is spent in use, not in design or implementation. So, why does conventional wisdom insist that software engineers focus primarily on the design and development of large-scale computing systems?
In this collection of essays and articles, key members of Google’s Site Reliability Team explain how and why their commitment to the entire lifecycle has enabled the company to successfully build, deploy, monitor, and maintain some of the largest software systems in the world. You’ll learn the principles and practices that enable Google engineers to make systems more scalable, reliable, and efficient—lessons directly applicable to your organization.
Betsy Beyer
Betsy Beyer is a Technical Writer for Google in New York City specializing in Site Reliability Engineering. She has previously written documentation for Google’s Data Center and Hardware Operations Teams in Mountain View and across its globally distributed datacenters. Before moving to New York, Betsy was a lecturer on technical writing at Stanford University. En route to her current career, Betsy studied International Relations and English Literature, and holds degrees from Stanford and Tulane.
Chris Jones
Chris Jones is a Site Reliability Engineer for Google App Engine, a cloud platform-as-a-service product serving over 28 billion requests per day. Based in San Francisco, he has previously been responsible for the care and feeding of Google’s advertising statistics, data warehousing, and customer support systems. In other lives, Chris has worked in academic IT, analyzed data for political campaigns, and engaged in some light BSD kernel hacking, picking up degrees in Computer Engineering, Economics, and Technology Policy along the way. He’s also a licensed professional engineer.
Jennifer Petoff
Jennifer Petoff is a Program Manager for Google’s Site Reliability Engineering team and based in Dublin, Ireland. She has managed large global projects across wide-ranging domains including scientific research, engineering, human resources, and advertising operations. Jennifer joined Google after spending eight years in the chemical industry. She holds a PhD in Chemistry from Stanford University and a BS in Chemistry and a BA in Psychology from the University of Rochester.
Niall Richard Murphy
Niall Murphy leads the Ads Site Reliability Engineering team at Google Ireland. He has been involved in the Internet industry for about 20 years, and is currently chairperson of INEX, Ireland’s peering hub. He is the author or coauthor of a number of technical papers and/or books, including "IPv6 Network Administration" for O’Reilly, and a number of RFCs. He is currently cowriting a history of the Internet in Ireland, and is the holder of degrees in Computer Science, Mathematics, and Poetry Studies, which is surely some kind of mistake. He lives in Dublin with his wife and two sons.
第一部分 概览 第1章 介绍 1. DevOps分离的团队模型存在的问题 1.1 直接成本:Ops成本与系统 负载线性相关 1.2 间接成本:Dev/Ops沟通协调 1.2.1 运维团队:运维流程 1.2.2 开发团队:补丁、开关、插件等各种形式要求快速上线绕过运维团队的流程 2. DevOps还是SER 2.1 DevOps是...
评分 评分看这本书时做的笔记. 总结一下: 1. 有众多可以参考的地方, 例如 Cron 的设计, 监控的改进, 新工具的推广方法 2. 对手头的系统和工具要非常了解, 这样就可以玩出很多招数 1. 介绍 DevOps 在 Google 的实践 传统开发/运维分离的解决方案在规模扩大后沟通成本上升(“随时发布” vs...
评分第一部分 概览 第1章 介绍 1. DevOps分离的团队模型存在的问题 1.1 直接成本:Ops成本与系统 负载线性相关 1.2 间接成本:Dev/Ops沟通协调 1.2.1 运维团队:运维流程 1.2.2 开发团队:补丁、开关、插件等各种形式要求快速上线绕过运维团队的流程 2. DevOps还是SER 2.1 DevOps是...
评分翻完觉得做个eng真是难 还有点无趣 更不想工作了
评分基本是些常识性/人之常情的东西吧,并没有什么特别独特的地方.
评分最大的感觉:就像内功心法,能领会的人一般已有套路,没套路的人也难get全心法。
评分捡了几章名字感兴趣的看了以后,主要是borgmon, load balancing和distributed consensus,对这本书是相当失望。最大的问题是,这本书很难让人跟上思路并且开始思考,很多地方都在堆概念堆步骤,于是后果就是,只有你在真正开发和运维这一块的时候,你才有可能借鉴到一点东西,而另一个问题是,这本书对每一块东西又没有具体把整个思想的前因后果讲清楚,很难把类似的概念对应到自己的产品上。在亚麻,创业公司,微软都做过很多类似的工作,有可能是因为已有的cloud技术已经把这些运维的难点覆盖的差不多了,并没有觉得这本书有太多收获。
评分翻完觉得做个eng真是难 还有点无趣 更不想工作了
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 book.quotespace.org All Rights Reserved. 小美书屋 版权所有