走出边缘 下载 pdf 电子版 epub 免费 txt 2025

作为比较政治经济学经典著作之一，《走出边缘》为我们讲述了韩国、中国台湾地区、中国香港地区、新加坡、墨西哥和巴西六个新兴工业化经济体经济增长的政治故事（Politicalstory）。在指出新古典和依附理论都忽视了国内政治之后，哈格德教授从国际系统、国内联盟、政治制度和理念四个分析层次对六个经济体增长路径或者产业战略的选择做出了解释。在这里，政府、利益集团与市场关系（或者是国家、社会与经济关系）的跨时空比较得到了很好的展现。本书对理解“中国奇迹”的意义不在于回答了“中国是否符合东亚模式”这一宏观问题，也不在于提供了能够解释中国经济增长的若干论点，而在于为我们提供了一个分析问题的视角：不同的增长战略有着不同的政治基础或者政治条件。

致谢

中文版序言

导论

第一编 理论：成长的政治经济学

第 1 章 新古典和依附论的视角

第 2 章 解释发展战略

第二编 历史：比较视野下的工业化

第 3 章 韩国：从进口替代到出口导向型增长

第 4 章 中国台湾地区：从进口替代到出口导向型增长

第 5 章 新加坡和中国香港地区：向出口导向型增长的转型

第 6 章 二十世纪七八 十年代的东亚新兴工业化经济体：调整的政治

第 7 章 比较视野下的墨西哥和巴西：两种进口替代的轨道

第三编 争论：依附、平等和民主

第 8 章 外国直接投资与依附问题

第 9 章 产业战略与收入分配

第 10 章 威权主义与民主：重新审视政治制度和经济增长

索引

译后记

Stephan Haggard is Professor of Political Science at the University of California, San Diego.

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：走出边缘在线阅读

在线听书地址：走出边缘在线收听

在线购买地址：走出边缘在线购买

暂无原文赏析，正在全力查找中！

书籍介绍

作为比较政治经济学经典著作之一，《走出边缘》为我们讲述了韩国、中国台湾地区、中国香港地区、新加坡、墨西哥和巴西六个新兴工业化经济体经济增长的政治故事（Politicalstory）。在指出新古典和依附理论都忽视了国内政治之后，哈格德教授从国际系统、国内联盟、政治制度和理念四个分析层次对六个经济体增长路径或者产业战略的选择做出了解释。在这里，政府、利益集团与市场关系（或者是国家、社会与经济关系）的跨时空比较得到了很好的展现。本书对理解“中国奇迹”的意义不在于回答了“中国是否符合东亚模式”这一宏观问题，也不在于提供了能够解释中国经济增长的若干论点，而在于为我们提供了一个分析问题的视角：不同的增长战略有着不同的政治基础或者政治条件。

• 作者：雨果街面包超人 发布时间：2018-08-08 13:53:31

  读完了确定自己不能做学术 就单单写reference我就会自杀

• 作者：研二苗 发布时间：2019-06-05 20:46:11

  定性比较是作者强项，但在本书中有的细节略显琐碎。一个takeaway：阶级，产业部门联盟视角对政策分析有助于构建简洁宏大的理论，但有时在历史的细节上难以经受住细致的考察。尤其是在后发国家中，产业联盟往往是发展战略的结果而非原因。此时，精英所面临的约束条件与激励以及其意识形态就显得更为重要了。

• 作者：兰幽谷 发布时间：2019-08-26 19:20:09

  适合影视化的小说，少一些情感纠葛，多一些研发过程就更好了。

• 作者：逗妃娘娘 发布时间：2020-08-10 13:47:40

  进口替代工业化（巴西、墨西哥）；出口导向型工业化（韩国、中国台湾）；转口贸易—出口导向（新加坡、中国香港）

• 作者：草昧 发布时间：2022-11-23 22:33:38

  看了一，二编，作者的选题与思路都很认同，但感觉写的不太好，看了下材料 梳理，不如用平实的语言写本书

• 作者：游砂 发布时间：2013-11-24 20:27:01

  政治与发展战略；进口替代与出口导向的过渡；涉及威权与民主的影响

• 全书要点整理

  作者：颜禾 发布时间：2020-04-13 22:03:47

  【注意事项】

  要吃盐、红糖水不超过10天、产后第一周不喝老母鸡汤、喝汤也要吃肉

  每天鸡蛋不超过2个、忌吃很多酱油、醋，忌吃味精、

  哺乳期忌吃巧克力

  忌乳房胀痛时热敷，可以冷敷

  忌冷水刷牙、忌碰冷水

  忌用香皂洗乳房

  产后忌立刻熟睡

  宜穿有后跟的拖鞋

  宜穿着袜子睡觉

  宜穿高腰裤护脐

  忌随意用蚊香

  前三天指漱刷牙

  保证每天8~9小时睡眠

  睡觉不要长期朝一个方向侧卧，会挤压乳房，容易引起两侧乳房发育不平衡

  做做眼保健操

  坚持乳房按摩

  产后代谢快，可敷面膜保养皮肤

  继续凯格尔运动

  【剖腹产】：

  忌术后6小时进食

  宜术后6小时喝萝卜汤排期

  术后6小时不能枕枕头

  术后初期（6小时后）采取侧卧位

  多吃鸡蛋、瘦肉、水果和蔬菜

  产后不宜平卧，宜侧卧位（身体和床20~30度）

  术后7天内使用腹带

  忌吃辣椒等辛辣食物

  7天后饮食与顺产妈妈一样

  第二天：红糖桂圆小米粥、苹果

  小米粥、当归鲫鱼汤

  黑芝麻糊

  西红柿面片汤

  第三天：香蕉、红枣板栗粥

  小米饭、清炒菠菜、当归生姜羊肉煲

  枸杞红枣粥

  木耳炒腰花、鲢鱼丝瓜汤

  第四天：西红柿鸡蛋、黄花豆腐瘦肉汤

  鱼头香菇豆腐汤、炒青菜

  第五天：虾仁馄饨、

  清炒荷兰豆、花生猪蹄汤

  香蕉、鸡蛋羹

  菠萝鸡片、奶汁百合鲫鱼汤、黑芝麻糊

  第6天：

  煎鸡蛋、豌豆小米粥、

  瘦肉冬瓜汤

  小米粥、糖醋里脊、虾皮豆腐

  第7天：

  黑米粥、

  甜椒鸡丁、西蓝花鹌鹑蛋汤

  香菇肉片、鱼片粥

  【新生儿】：

  忌喂奶超过30分钟

  不要抱着宝宝睡觉，也不要拍着宝宝，嘴里哼歌来回走动

  忌频繁亲吻宝宝

  忌用闪光灯给宝宝拍照

  忌抱着宝宝摇晃

  宜用沸水消毒奶具

  宜做好脐带护理：75％医用酒精，从内而外擦脐带，每天2~3次，保持脐带干爽，用纱布盖好

  不要剃“满月头”

  【月子期间饮食】

  【绿灯食物：】鲫鱼、红豆（消水肿、补血）、猪蹄、公鸡、豆浆、玉米、香蕉、菠菜、白菜、南瓜、黑芝麻、核桃、小米（不能天天吃）、胡萝卜、苹果、猕猴桃、红薯、西红柿、黑木耳、牛奶、牛肉、红枣、豆腐、鸡蛋、猪肝、茶油

  【黄灯食物】：花椒、茴香，甜食

  【红灯食物】：橘子、西瓜、柿子、酸咸食物、浓茶、咖啡、碳酸饮料、油炸食品；生、冷、硬的食物

  【特殊需求的食物】

  下奶食物：花生、猪蹄、鲫鱼、莴笋、米酒（？）、黄花菜

  抗抑郁食物：花生、香蕉、瓜子、核桃、新鲜绿叶食物、海产品、蘑菇、动物肝脏、黄花鱼

  缓解乳房胀痛：豌豆、丝瓜、桔梗红豆粥

  补血食物：肉类、蛋类、海产品（海带、紫菜、海鱼）、动物肝脏、动物血、红枣、花生、木耳；三色补血汤（南瓜＋银耳＋莲子＋红枣＋红糖），猪肝炒油菜，木耳炒鱿鱼（剖腹产不能吃鱿鱼）

  补钙：牛奶、骨头汤、豆制品、水果；黄豆莲藕排骨汤

  补虚：黄鳝粉丝煲、银鱼苋菜汤、猪肚粥

  助排恶露：山楂红糖、阿胶鸡蛋羹、益母草煮鸡蛋

  消肿：西蓝花、鲤鱼红枣汤、莴笋猪肉粥

  塑形瘦身（产后第6周后）：冬瓜、魔芋、海带（海带烧黄豆）

  【月子餐】

  按时间顺序：

  第一周：

  花生红枣小米粥、西红柿菠菜面

  红糖小米粥

  胡萝卜小米粥

  肉末蒸蛋

  红薯粥

  红枣莲子糯米粥

  西红柿菠菜蛋花汤

  黑木耳炒鸡蛋

  嫩炒牛肉片

  清炒黄瓜

  玉米胡萝卜粥

  西红柿炒蛋

  鸡蛋红枣羹

  清炒黄豆芽

  空心菜排骨汤

  第二周：催乳、补钙、补血

  鲤鱼汤

  黑木耳炒蛋

  嫩炒牛肉片

  海带炒豆皮

  香菇瘦肉粥（大米＋小米＋糙米）

  多补血：猪心、红枣猪蹄、红衣花生、枸杞；

  泌乳：鸡汤、鱼汤、排骨汤、豆腐汤

  明虾炖豆腐

  清炒芦蒿

  荔枝粥（大米＋干荔枝）

  猪蹄茭白汤（促进乳汁分泌）

  花生红豆汤

  南瓜青菜粥

  空心菜排骨汤

  胡萝卜丝

  核桃百合粥、苹果

  红薯

  补铜：动物肝脏，猪肉、黑芝麻、荠菜、大豆、龙须菜、芋头、青菜

  补钙：牛奶、鸡蛋

  黑芝麻米糊：大米＋莲子＋黑芝麻洗干净晒干，榨成粉→加水煮熟

  芋头排骨汤、

  莲子猪肚汤

  牛奶银耳小米粥

  核桃莲藕汤

  芹菜牛肉丝

  腐竹玉米猪肝粥

  丝瓜蛋汤

  豌豆排骨粥

  海带豆腐汤

  西红柿豆腐汤

  西芹炒百合

  菠菜玉米粥（菠菜＋玉米糝）

  第三周：宝宝要补充维D，可适当多晒太阳；补血益气通乳

  芹菜牛肉丝

  猪骨萝卜汤（猪骨＋白萝卜＋胡萝卜）

  猪蹄茭白汤

  西蓝花彩蔬小炒（西蓝花＋玉米粒＋胡萝卜丁＋青椒丁＋红椒丁）

  红枣枸杞粥

  炖鸡汤

  芦笋炒肉丝

  鱼头豆腐汤

  胡萝卜丝

  木瓜鲈鱼汤

  虾皮粥

  西红柿炒蛋

  白斩鸡

  海带豆腐汤

  核桃黑芝麻花生粥

  板栗烧牛肉

  莲子猪肚汤

  香菇鸡片

  鱼丸苋菜汤

  玉米西红柿羹

  山药羊肉羹

  豌豆炒虾仁

  猪肝

  香菇豆腐

  芹菜

  牛肉粉丝汤

  冬瓜猪蹄煲

  清炒菠菜

  枸杞乌鸡汤

  炒豆皮

  莲藕炖牛腩

  西芹炒百合

  第四周

  芹菜牛肉丝

  三丁豆腐汤（豆腐＋鸡胸肉＋西红柿＋豌豆）

  猪肝炒油菜

  鸡蛋玉米羹

  鲜奶南瓜羹

  豌豆炒虾仁

  丝瓜蛋汤

  红豆黑米粥

  猪排炖黄豆芽汤

  芦笋炒肉丝

  菠菜鱼片汤

  胡萝卜牛蒡排骨汤

  腐竹小米猪肝粥

  栗子黄鳝煲

  青菜蛋花汤

  三鲜冬瓜汤（冬瓜＋冬笋＋西红柿＋油菜＋鲜香菇）

  西红柿烧豆腐

  猪蹄茭白汤

  双菇炒鸡肉（鸡蛋＋鸡胸肉＋金针菇＋金针菇）

  鸭肉粥

  肉片炒蘑菇

  清炒芦蒿

  清蒸鲈鱼

  西芹百合

  红枣银耳羹

  三丝牛肉（牛肉＋黑木耳＋胡萝卜＋菠菜）

  莲藕炖牛腩

  清炒茭白

  香菇玉米粥

  莴苣

  肉末豆腐羹

  香菇鸡汤

  肉末粥

  清炒藕片

  第五周

  红豆排骨汤

  花生粥

  西红柿鸡片（鸡胸肉＋荸荠＋鸡蛋清＋西红柿）

  芹菜炒土豆丝

  萝卜炖牛筋

  菠菜板栗鸡汤

  黄鱼豆腐煲

  猪肝红枣菠菜粥

  鲜虾西芹

  胡萝卜蘑菇汤

  西红柿鸡蛋汤

  香蕉

  腐竹拌黄瓜

  芹菜竹笋汤

  黄花菜炒猪腰

  鲤鱼汤

  雪菜豆腐汤

  藕拌黄花菜

  冬瓜丸子汤

  芋头排骨汤

  清炒绿豆芽

  丝瓜豆腐鱼头汤

  南瓜粥

  白菜排骨汤

  第六周：

  炒猪肝

  紫菜豆腐汤

  白萝卜海带汤

  南瓜油菜粥

  山药香菇鸡

  冬瓜海带汤

  西蓝花牛柳

  清炒冬瓜

  羊肉粉丝汤

  白菜香菇

  清炒绿豆芽

  莲藕瘦肉麦片粥

  清炒菠菜

  豆腐鲤鱼汤

  芹菜炒香菇

  翡翠豆腐羹

  小米粥

• Notes: Site Reliability Engineering

  作者：masterplan 发布时间：2017-05-11 08:28:11

  看这本书时做的笔记. 总结一下:

  1. 有众多可以参考的地方, 例如 Cron 的设计, 监控的改进, 新工具的推广方法

  2. 对手头的系统和工具要非常了解, 这样就可以玩出很多招数

  1. 介绍

  DevOps 在 Google 的实践

  传统开发/运维分离的解决方案在规模扩大后沟通成本上升(“随时发布” vs. “不再改动”) -> 新型运维团队 SRE(50%-60%标准开发, 其他为85%-99%能力的开发, 为了开发系统代替手工操作) -> 最多 50% 时间用于运维工作, 余下开发系统来自动化

  SRE 方法论

  * 运维工作最多占用 50% 时间

  * 遇到故障事后写总结

  * 因为信息系统的特点, 不是也不该追求 100% 可靠, 给出现实的可靠性. 在实现这个可靠性的前提下, SRE 可以做各种创新

  * 监控, 通过预案/手册缩短平均恢复时间

  * 70% 的事故源于部署变更 -> 渐进发布, 精确检测, 回滚机制

  2. 生产环境

  集群资源分配: Borg(分布式集群操作系统), 下一代 Kubernetes(2014)

  * Large-scale cluster management at Google with Borg

  * Borg, Omega, and Kubernetes

  * 负责运行用户提交的任务. 每个任务由多个实例组成, Borg 会为每一个实例安排一台物理服务器, 执行具体的程序启动它

  * 负责任务的监控, 如果异常, 终止并重启

  * 命名: BNS: /bns/<cluster>/<user>/<task>/<instance>

  * 任务需要在配置中声明其所需的具体资源(cpu/mem), 超过则立即 kill

  * 存储

  * 分布式存储, 小文件和大文件进不同的集群.

  * 单个集群一年内会损失上千块硬盘, 数据中心有专门的团队来处理

  网络

  * 这些概念比较陌生, OpenFlow 的软件定义网络, 带宽控制器优化带宽.

  * 从地理位置, 用户服务和远程调用三层进行负载均衡

  监控报警

  * 定时抓取指标, 超出触发报警

  * **新旧版本的对比: 新版本是否让软件服务器更快了?**

  * 检查资源用量随时间的变化, 制定资源计划.

  服务

  * 所有服务使用 RPC 通信, 开源实现为 gRPC

  * 格式为 Protocol Buffer(与 Apache Thrift 相比) (大小比 xml 小 3-10 倍, 序列化/反序列化快 100 倍) (和 json 比?)

  * 服务和存储根据流量分散到各大洲的机房

  开发

  * Code review

  3. 拥抱风险

  目标

  * 没有 100% 可靠的服务, 达到一定程度的可靠性之后, 应把精力转向他处.

  * **”当设立了一个可用性目标为99.99%时, 我们即使要超过这个目标, 也不会超过太多, 否则会浪费为系统增加新功能, 清理技术债务或者降低运营成本的机会.”**

  * 可靠性目标成为错误预算: 提供明确和客观的指标决定服务在一个季度中接受多少不可靠性(用于 SRE 部门和产品部门的沟通). 只要错误预算耗尽, 新版本的发布就会暂停(?但是错误率由 SRE 部门提供, 而发布由产品决定?) -> 认为风险由产品开发决定, 一个变通是, 当错误预算即将用尽时, 降低发布的频率. 即使是网络中断或者数据中心故障影响了错误率, 发布频率也会降低, 因为”每个人”都有义务保障服务的正常运行.

  * 可用性指标: 请求成功率. **用我们记录的请求成功率与用户期望的服务水平做对比.**

  成本

  * 可用性: 99.9% 到 99.99%; 收入: 1000000刀 -> 改进后的价值: 1000000 * 0.09% = 900 刀

  需求

  * 面向消费者需要低延迟(队列空为好), 离线计算需要吞吐量(队列满为好). 需要分别响应不同的需求. -> 两个集群, 低延迟/高吞吐量

  4. 服务质量

  质量度量

  * 请求延迟 (Req time)

  * 错误率 (Web errors)

  * 吞吐量 (Web QPS)

  * Google 云计算的可用性指标: 99.95% -> 60*24*365*0.0005 = 262.8 min/year -> 我们的可用性?

  特色

  * 4/5个指标, 多/少都不好.

  * 监控, y 轴指数分布

  * 数据收集每10秒一次, 每一分钟汇总一次. 目标像这样: **99% 的 get RPC 调用在 < 100ms 的时间内完成.**, 每天可以出一个这样的报表.

  总结

  * 指标越少越好, 少到不能更少

  * 性能指标保持简单

  * 从松散的目标开始, 逐渐收紧. 不要一开始就追求完美

  * 对内指标要求可以比对外高一些, 留有余地

  5. 琐事

  琐事指与规模线性增长的手动事务, 占用 Google SRE 大约 33% 的时间

  6. 分布式系统的监控

  方式

  * 白盒: 系统内部数据

  * 黑盒: 外部响应

  * Dashboard: 可视化, 提供选择/过滤功能

  * 警报

  如何监控

  * 对照组: 上周, 上一个版本

  * 减少报警量(防止”狼来了”)

  * 简单快速的逻辑. 不要自动学习阈值(这点和我想的不一样)

  避免在监控系统中维护复杂的依赖关系

  方法论

  * 故障, 警报, 定位和调试都必须保持简单!

  * 4个关键指标: 延迟, 流量, 错误率, 饱和度(IO 带宽占用比, 磁盘占用比)

  长尾

  * 重要的是分布而不是平均 -> 直方图 Y 轴指数展示

  复杂性管理

  * 避免监控系统变得过于复杂

  7. 自动化系统的演进

  * shell 脚本 -> 改进后的 Python 单元测试框架(Prodtest, 改进的 Python 单元测试框架, 可用来对实际服务进行单元测试), 用于验证集群中的服务(比如 DNS 是否存在/成功)

  * 在 Prodtest 出来之后, 又为每个 test 创建了对应的修复工具.

  * 集群上线系统的测试-自动化修复套件的问题:

  1. 需要维护!

  2. 分布式自动化依赖于 SSH, 需要 root 权限执行. => 需要将 SRE 完成任务所需权限降到最低. => 使用有 ACL 的本地 admin 进程取代 sshd, admin 记录 rpc 请求者, 参数和结果.

  * Borg: 成功的核心是”把集群管理变成了一个可以发送 API 的中央协调主体”. 所以 shell 脚本 => Python 集群测试框架(自动化系统) => Borg(自治系统, 将集群管理抽象为单机环境) => 自治系统强调自我检查和自我修复.

  * 自动化的问题: 自动化多了, 人就忘了手动该怎么做. 甚至系统将不再有手动操作的接口.

  8. 发布

  * 构建过程的封闭性, 不受构建机器上第三方类库和其他软件工具影响. 编译过程自包含, 不依赖编译环境之外的其他服务.

  * 构建工具与被构建的项目放在同一个仓库. (而我们的做法是分离的. 应用开发者按照平台提供的规范走, 不管构建的事. 各有好处. 这样平台在构建过程上可发挥的空间更大)

  * 单独的发布分支(避免引入之后主分支上的改动). 发布系统将创建新的发布分支, 编译, 跑单元测试. 每一步都有日志记录.

  * 部署. “提供一系列可扩展的 Python 类, 支持任意部署流程”. 同时会对流程进行监控.

  * 经验: 在规模不大时就考虑发布工程, 尽早采用最佳实践(尽早建立平台团队?)

  9. 简单化

  * 问题: 代码膨胀. 态度: “每一行新代码都是负担”, less is more.

  * 方法: 最小 API(方法更少, 参数更少), 模块化(定义良好的边界)

  10. 基于时序数据的报警

  SRE 的职责层级关系(低 -> 高):

  监控

  应急处理

  事后总结和问题根源分析

  测试

  容量规划

  研发(50%+ 的精力)

  监控首当其冲.

  * 方法论: 单机问题报警没有意义(太频繁).

  * 模型: 探针(脚本返回值 + 图形展示) 转到时序信息监控. 收集回来的数据同时进行展示和报警, 报警规则由数学表达式表示.

  * 接口: /varz HTTP 列出所有的监控变量值, 由 Borgmon 定时抓取. (看来在应用所在每个机器上都有)

  * 报警: 每条报警规则都有一个持续时间, 只有当警报持续时间超过一定范围之后才触发报警. (有借鉴意义, 尤其是对可自动恢复的问题); 同时多条连续的报警信息可以合并.

  11. On-call

  * 运维工作时间上限是50%工作时间, 其中不超过 25% 的 on-call.

  * 分钟级的 ack. 比如 99.99% 可用的系统, 每个季度有 13 分钟的不可用时间, 那么 on-call 必须在 13 分钟之内解决问题(不过这里的”问题”看来是影响全局服务的大问题)

  * “面临挑战时, 人有两种处理模式: 1. 依赖直觉, 快速, 自动化行动 2. 理性, 专注, 有意识认知活动. 为了确保 on-call 采用第二种方式, 必须减少其压力. 医学上讲, 压力状态下释放的荷尔蒙, 如 xx 和 yy, 可能造成恐惧, 进而影响正常认知..” 哈哈哈, 这个态度我喜欢, 必须把不理性的情况考虑到, 避免运维压力过大.

  12. 故障排查

  * 大型系统中, 遇到问题首要做的是尽可能恢复服务, 而不是查找问题根源.

  * 将故障排查测试的项目明确写出来, 同时公布测试结果.

  13. 紧急响应

  * 演习: “SRE 故意破坏系统, 模拟事故, 然后针对失败模式进行预防以提高可靠性” => 鼓励主动测试

  * Panic room: 专用的灾难安全屋, 有生产环境的专线连接.

  14. 紧急事故管理

  * 出了事故, on-call, 开发, 管理者, 这些关注到的人都在用自己的方法查找并尝试解决问题.

  * 都在查找原因, 没有人有精力和时间思考如何通过其他手段缓解当前的问题.

  * 没有时间清晰和有效地与其他人进行沟通, 没有人知道他们的同事在干什么.

  * 解决: 职责分离. 有事故总控(需要明确声明现在开始全权负责, 任务分配), 事务处理团队, 发言人和规划负责人(提供支持).

  15. 事后总结

  * 总结: 1. 记录事故 2. 理清根源 3. 采取有效措施使得重现概率最低

  * 对事不对人

  * 总结报告需要评审

  * 举办演习, 再现某篇事故总结事故, 一批工程师扮演文档中提到的角色

  * 激励做正确事情的人(“良好的事后总结和事故处理可以赢得从 CEO 到工程师的一致好评”)

  16. 跟踪故障

  * 报警的聚合(一个问题引发了一连串报警)和加标签.

  17. 测试可靠性

  没看懂. 摘一下最后一句话: ”写出优质的测试需要付出的成本是很大的”. 现在写写单元测试没问题, 依赖众多的分布式软件的集成测试还不明白怎么弄.

  18. SRE 部门中的软件工程实践

  * 分析了一个案例, 对扩容需求做了一个应用, 包括需求的定义语法规则和对应的问题求解器. 一开始是简单的启发式逻辑, 后来使用线性规划使其更加聪明. 总结是体现了”发布与迭代”的思路, 不是一开始就期待完美的设计, 而是不断继续前进.

  * 讨论了新工具的推广. 公告邮件和简单的演示是不够的, 需要持续和完整的推广方案, 用户的拥护和管理层的帮助. 设计的时候, 要时刻从用户角度提高可用性.

  * 不要陷入对”完美的最终产物”的想象中. 一个”最小可行产品”是必要的, 在此基础上进行递进式的, 稳定的小型发布.

  * 后期引入有统计学和数学优化背景的人进行优化.

  19. 前端负载均衡

  一致性哈希.

  负载均衡器的包转发:

  * NAT, 需要在内存中追踪每一个连接, 否定

  * 修改数据链路层信息(MAC 地址), 需要后端服务器在一个局域网, 否定

  * 包封装, 将请求使用路由封装协议封装到另一个 IP 包中, 使用后端服务器地址作为目标地址, ok.

  20. 数据中心负载均衡

  * 随机轮询:

  1. 多个进程共享某个后端时, 其客户端请求速率可能是不同的. 如果一台后端上恰好跑的都是请求速率块的进程, 那么其负载就高.

  2. 物理服务器不同

  * 最闲轮询:

  问题是, 一些任务在处理过程中是跑满了 cpu, 一些则是在阻塞. 但最闲轮询(基于任务数量)会认为负载是一样的.

  * 加权轮询:

  将最闲轮询的”任务数”替换为综合请求速率, cpu 占用率等计算出的值, 实践中效果更好.

  21. 过载

  22. 连锁故障

  连锁故障由故障进入正反馈引发. 典型的例子是: 一个集群故障 => fallback 到另一个集群 => 另一个集群某服务受影响变慢 => RPC 超时, 大量重试 => 这个集群也不堪重负挂掉.

  * 应对方法: 压力测试极限, 提供降级结果, 在可能导致问题时主动拒绝请求.

  * 去除同层调用, 保持调用栈持久向下.

  * 压力测试, 直到出现故障

  23. 分布式共识

  * 问题定义: 异步式分布式共识在消息传递可能无线延迟的环境下的实现

  * 不能通过简单心跳实现

  * 不稳定的条件下, 没有任何一种异步式分布式共识算法可以保证一定达成共识

  * Paxos: 有严格顺序的提案被大多数接收者同意, 已被 zk, consul, etcd 等封装. 最出版本的 Paxos 有性能问题

  * 复合式 Paxos: Paxos 两阶段: prepare/promise, 允许跳过第一阶段. 但是有锁住的危险. 更好的算法参考 Raft.

  24. Cron

  这里的 cron 是允许错过的, crond 不记录执行信息, 只会记录 schedule.

  定义问题

  cron 分为两类: 可重复的(垃圾回收)和不可重复的(邮件发送).

  上面是跑多了的情况, 也有跑少了的情况: 有的 cron 允许错过一次(垃圾回收), 有的不允许(每月结算)

  这两种情况导致 cron 的错误建模很复杂. **本文偏向于错过运行, 而不是运行两次**, 因为错过可以手动启动一次, 跑了两次是覆水难收的.

  总结: 可以少跑, 不能重复跑

  大规模部署

  最小周期也是每分钟.

  也是使用的容器, 主要考虑的功能是进程隔离: 一个进程不该影响到另外的进程.

  容错. 调度器确保在数据中心的另一个地方有备份.

  总结: 最小粒度每分钟, 调度器有多重实例, 通过 paxos 确保一致性

  Cron at Google

  对 cron 的状态, 有两种选择:

  * 存到分布式存储(GFS)

  * 存到 cron service

  选择的第二种. (GFS 适合大文件存储)

  使用 Paxos 算法确保 cron service 的一致性. paxos: 通过多重不可靠的副本达成可靠的一致性.

  最重要的信息是

  哪个 cron 已经跑过了.

  cron 调度器有多个备份待命, master 负责启动 cron job.

  master 的工作流程:

  sleep 直到时间到, 向 data center scheduler 发出启动指令,

  同时发 paxos, => 其他 replica 知道任务已经启动

  启动完毕后再发 paxos. => 其他 replica 知道任务启动完毕

  => cron job 跑完自己结束(解决了并行执行的问题), master 只管启动, 但是一定要成功启动.

  确保只有一个调度器与 data center scheduler 交互, 一旦失去 master 地位, 就停止交互.

  这里”发 paxos 告知开始启动”和”发 paxos 告知启动完成”中间有个时间段, 这个时间段就是启动时间. **这点很好, 现在 marathon 缺少这个, 你可以告诉他要做什么任务, 但他不会告诉你什么时候完成**

  总结: cron 启动状态通过 paxos 与备份同步, 确保只有 master 能与 data center scheduler 交互, 只管启动不管结束

  启动失败

  再次重申, cron job 启动时候有两个同步点: 开始启动和启动完成. 如果 master 在这二者的中间失败, 我们就难以知道启动是否真正完成.

  解决方法是使启动操作(master => 启动操作(data center scheduler 执行) => 完成)都是可重入的. 启动操作实际上是一系列的 rpc 操作(我想是类似 redarrow?)

  不可避免的是失败. 如果在 rpc 发出 - 启动状态发送到 paxos 之间 master 挂掉, 那么新的 master 可能不知道这个 cron 已经启动, 还是可能导致重复启动. 这种小概率的事件就看你要不要继续付出代价来防了.

  存储状态

  paxos 基本是一个状态变化的连续日志. 这带来两个问题: 1. 日志分段 2. 日志存储

  日志分段用打 snapshot 的方式解决: 我猜这里是把日志分成两部分: 之前的日志打成 snapshot, 之后的作为增量. snapshot 保险存放. 那么即使丢失, 丢掉的也是增量, 在一个可控的范围内.

  对日志存储, 有两个选择: 分布式存储和系统本地卷. 选择是两种都做: 在所有 master 和备份的本地存(一共3个), 同时写到分布式存储.

  大规模带来的问题

  大规模: 为上千台节点的 data center 提供 cron 服务. 如果这些 cron 都集中到同一时间段就不好了. 举例: 当想要一个每天跑一次的 cron 时, 很多人都会写:

  `0 0 * * *`, 拿这时候的 cron 密度就比较高.

  提供了一种新格式, `? ? * * *` 表示由 cron master 选 cron 时间, cron master 利用这种写法将其均匀分布:

  

  Google 全局 Cron: 时间-任务数量

  25. 数据处理流水

  跳过

  26. 数据完整性

  灾备做得非常 nice.

  案例: gmail 丢失了大量用户数据, 系统中存在的很多安全防护措施, 内部检查机制, 冗余备份失效. => 从 gtape 恢复. 来自于”深度多层防御”的系统.

  1. 任何一个单独的防御措施可能失效

  2. 某一个级别(磁盘)的防御措施可能失效, 所以要依靠完全不同的介质. 最好的数据完整性保障手段一定是多层的.

  案例: google music 音乐被服务误删 => 同时进行软件的恢复和磁带的恢复(由卡车从异地存放点拉过来)

  27. 大规模发布

  讨论了发布规范, 容量规划, 故障预期, 客户端行为处理, 手动事项的文档化, 发布对外部依赖的影响.

  灰度发布: 先安装几台机器, 监控一段时间. 没有异常的话再继续.

  28. 培养 SRE

  作为新手, 培养体系值得一看:

  * 设计具体的, 有延续性的学习体验

  * 鼓励思考问题本质(通过反向工程, 统计学进入系统)

  * 从失败中学习

  * 见习 on-call

  * 让学员与老手一起修订培训计划

  * 正式参加 on-call 是一个里程碑

  “对很多内省性性格的成员来说, 培训过程中的混乱或者不确定性会导致他们学习速度变慢, 甚至无法适应.”

  培训:

  指定一个顺序, 比如可以按照服务发生时请求的顺序: 请求 -> 前端服务 -> 中层服务 -> 基础设施 -> 整体.

  新手任务:

  功能修改 -> 增加新的监控 -> 增加新的自动化 -> 见习 oncall

  29. 处理中断性任务

  流状态: “在解决问题的过程中, 充分了解问题的起因和现状, 隐约感觉自己可以解决这个问题.”

  尽可能长时间待在流状态中, 减少上下文切换(“一次20分钟的中断性任务需要进行两次上下文切换, 而这种切换会造成数个小时的生产力丧失”), 对此, 应该延长每种工作模式的时间.

  30. 嵌入 SRE

  略过.

  31. 沟通协作

  团队构成: 技术负责人, SRE 经理

  “一般来说, 单人项目最终肯定会失败, 除非此人能力超强或者要解决的问题是非常简单直接的”

  32. SRE 参与模式

  略过.

  33. 其他行业的经验

  关注任何细节, 提供冗余容量, 模拟及线上演习, 重视需求, 纵深防御.

  34. 结语

  飞行员的例子: 100年前是两名飞行员, 100年后, 飞机的安全性, 容量, 速度, 可靠性发生了翻天覆地的变化, 但仍然是两名飞行员! 这说明飞机的人机接口经过了精心设计, 简单易用. 我们的系统也要具有这种特性.