小蚂蚁大国王 pdf mobi txt 2024 电子版 下载

晓曦的“小小昆虫记”系列绘本，让孩子们走进大自然，探知蚂蚁、蝴蝶、屎壳郎的生活，感受昆虫世界的脉博。它的童话绘本有科普知识的内涵，给人物和情节赋予新鲜有趣的味道；而科普绘本穿上了童话的盛装，贴合现代儿童趣味，启发儿童求知探索。引领孩子们探索大自然的奥秘，兼具实用性、教育性和趣味性，以孩子的好奇心和眼睛发掘自然界的丰富多彩，鼓励孩子们到户外去，跟随小昆虫的线索和印记去探寻，发现大自然的野趣。

小蚂蚁大国王 适读年龄：3-9岁 图书简介： 晓曦的“小小昆虫记”系列绘本，让孩子们走进大自然，探知蚂蚁、蝴蝶、屎壳郎的生活，感受昆虫世界的脉博。它的童话绘本有科普知识的内涵，给人物和情节赋予新鲜有趣的味道；而科普绘本穿上了童话的盛装，贴合现代儿童趣味，启发儿童求知探索。引领孩子们探索大自然的奥秘，兼具实用性、教育性和趣味性，以孩子的好奇心和眼睛发掘自然界的丰富多彩，鼓励孩子们到户外去，跟随小昆虫的线索和印记去探寻，发现大自然的野趣。 图书特点： l、每一本绘本故事的主人公均与小小昆虫记相互对应，用更加直观、科学的方式客观呈现科普知识。

2、小小昆虫记中不仅包含孩子们好奇的科普知识，还设置有“家庭互动任务”，进一步提升编读互动，家长与孩子的互动，图书与读者的互动。 3、由知名播音员结合图书内容，录制音频，并在喜玛拉雅上线，扫描书后二维码可以结合内容免费听书。 4、香港大公报推荐阅读。 5、作者为三届冰心儿童图书奖及文学奖获得者倾情推出。 6、本书获得绿色环保印刷标志，进口环保油墨印刷，使孩子们更加安全阅读，使家长更加放心。 7、书中知识点由中国林科院资源昆虫研究所权威指导。

暂无相关目录，正在全力查找中！

暂无相关内容，正在全力查找中

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

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

在线阅读地址：小蚂蚁大国王在线阅读

在线听书地址：小蚂蚁大国王在线收听

在线购买地址：小蚂蚁大国王在线购买

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

书籍介绍

晓曦的“小小昆虫记”系列绘本，让孩子们走进大自然，探知蚂蚁、蝴蝶、屎壳郎的生活，感受昆虫世界的脉博。它的童话绘本有科普知识的内涵，给人物和情节赋予新鲜有趣的味道；而科普绘本穿上了童话的盛装，贴合现代儿童趣味，启发儿童求知探索。引领孩子们探索大自然的奥秘，兼具实用性、教育性和趣味性，以孩子的好奇心和眼睛发掘自然界的丰富多彩，鼓励孩子们到户外去，跟随小昆虫的线索和印记去探寻，发现大自然的野趣。

小蚂蚁大国王 适读年龄：3-9岁 图书简介： 晓曦的“小小昆虫记”系列绘本，让孩子们走进大自然，探知蚂蚁、蝴蝶、屎壳郎的生活，感受昆虫世界的脉博。它的童话绘本有科普知识的内涵，给人物和情节赋予新鲜有趣的味道；而科普绘本穿上了童话的盛装，贴合现代儿童趣味，启发儿童求知探索。引领孩子们探索大自然的奥秘，兼具实用性、教育性和趣味性，以孩子的好奇心和眼睛发掘自然界的丰富多彩，鼓励孩子们到户外去，跟随小昆虫的线索和印记去探寻，发现大自然的野趣。 图书特点： l、每一本绘本故事的主人公均与小小昆虫记相互对应，用更加直观、科学的方式客观呈现科普知识。

2、小小昆虫记中不仅包含孩子们好奇的科普知识，还设置有“家庭互动任务”，进一步提升编读互动，家长与孩子的互动，图书与读者的互动。 3、由知名播音员结合图书内容，录制音频，并在喜玛拉雅上线，扫描书后二维码可以结合内容免费听书。 4、香港大公报推荐阅读。 5、作者为三届冰心儿童图书奖及文学奖获得者倾情推出。 6、本书获得绿色环保印刷标志，进口环保油墨印刷，使孩子们更加安全阅读，使家长更加放心。 7、书中知识点由中国林科院资源昆虫研究所权威指导。

• 作者：娱乐世代 发布时间：2021-12-17 18:53:04

  基本上就是历史上有名的那些事整合了，

• 作者：mado1983 发布时间：2014-01-18 15:40:34

  文字古雅，奇趣盎然，但始终略显平淡。

• 作者：纸裁缝 发布时间：2016-10-21 11:02:47

  很好学的Q版教程，对绘画水平要求不高，练习的过程很快乐，画完之后很开心

• 作者：水獭 发布时间：2016-04-17 17:59:20

  naul

• 作者：闲耘™ 发布时间：2022-01-15 12:55:15

  即使作为儿童绘本，感觉也是言之无物

• 作者：乡野老妪 发布时间：2023-06-16 13:54:20

  序言一写得很好，文笔精炼，作者文化底蕴，把中国建筑特点介绍清揭，也是我看过比较长的一篇序言，总共有30页，用速写画配图比较有意思，值得一看。

• 推荐这本提高情商的书，我后悔没有在更早的时候读过它！

  作者：大果情商 发布时间：2017-08-28 17:09:06

  今天想推荐大果仁一本书——《杀死一只知更鸟》，我很后悔没有在更早的时候仔细读、读懂它。引用一位豆瓣读者的话，

  “没有读过这本书的人生跟读过之后的人生，真的很不一样。

  ”而我大力推荐给你的理由，正是这是一本真正可以帮助我们提高情商的书：到底应该如何与别人相处？如何以正直的方式处理复杂的人际关系？如何做一个友善但坚持自我的人？这本书能给出答案。

  主要故事情节

  在美国三十年代大萧条时期一个叫梅科姆的南方小镇上，6岁的小女孩斯库特年幼丧母，跟作为律师的爸爸阿蒂克斯和哥哥杰姆一起生活。男孩迪儿来到姨妈家过暑假，杰姆和斯库特与他成为朋友。

  三个孩子被他们的隐居邻居所深深吸引，那个邻居叫做阿瑟.拉德利，谈起来就令人生畏，他把自己关在屋子里20多年，故事的第一部分就围绕三个孩子对这个怪人拉德利的好奇展开。梅科姆镇的人们不愿谈及拉德利，多年来也没有人见过他。孩子们则利用谣言编造了各种故事，推测背后隐藏的玄机，并设计一个又一个计划引他出门。在之后的两个暑假中，三个孩子发现，有人在拉德利家外的树上常给他们留小礼物。后来他们才知道这个人其实就是阿瑟。

  

  第二部分围绕一桩父亲阿蒂克斯为黑人辩护的案子而展开。

  阿蒂克斯被法院指定为汤姆.鲁滨逊辩护，后者是一位黑人，他被控强奸一位白人少女马耶拉.尤厄尔。虽然许多梅科姆镇人表示反对，但阿蒂克斯同意为汤姆辩护，有的孩子因阿蒂克斯而嘲笑杰姆和斯库特，称他们的父亲是"爱黑鬼的家伙"。斯库特甚至被挑衅为她父亲的荣誉而打架，而父亲告诉他别这么做。

  

  斯库特、杰姆和迪儿从黑人观礼台上偷偷旁听了对汤姆.鲁滨逊的审判。阿蒂克斯揭穿了原告马耶拉和她嗜酒的父亲鲍伯撒谎。是马耶拉主动向汤姆施加诱惑，而她父亲为此对她大打出手。虽然汤姆的无辜显而易见，但陪审团依然判他有罪。当绝望的汤姆越狱被杀时，杰姆与阿蒂克斯对司法公正的信念受到了极大的打击。虽然鲍伯胜诉，但他的名声扫地，他气急败坏的誓言报复。鲍伯当街淬了阿蒂克斯的脸。

  最后，一天晚上，当杰姆和斯库特从学校的万圣节盛会回家的时候，鲍伯突然对他们痛下毒手。杰姆的胳膊在打斗中折断，但在混乱中，一位陌生人救出了孩子们，这位神秘人将杰姆扛回家，斯库特认出他就是阿瑟.拉德利。

  在梅科姆小镇上，每个人认识每个人。固执守旧的亚历山德拉姑妈、通情达理的邻居莫迪小姐、爱搬弄是非的邻居芬克斯小姐、有教养的黑人保姆卡波妮、偏执乖张的杜博斯太太、正直仗义的白人雇主林克•迪斯、心似明镜的泰勒法官、自相矛盾的老师盖茨小姐........虽然时间地域文化间差距很大，

  但从人性看，梅科姆小镇与我们所处的环境并无二致，

  我们在自己的单位、学校、大家庭里都能认出性格与书中各种角色差不多的人。正是这样，读者才能够随着小女孩斯库特视角，在父亲阿蒂克斯身体力行的引导下，以最大的善意去认识这些人，在坚持自己主张同时用同理心跟他们相处。

  

  如何与别人相处？

  “在你最终了解他们之后，你会发现，绝大多数人都是好人”

  父亲阿蒂克斯告诉斯库特：“如果你能学会一个简单的小技巧，你就能和所有这些人相处得很好。除非你从别人的观点考虑问题——在你钻进别人的身体里四处游荡之前，你决不会真正了解他”

  阿瑟·拉德利把自己关在屋子里20几年，从来没有走出过家门一步。在街坊们的闲谈细语传言中，拉德力被想象成是一个“吃死老鼠、夜晚会出来走，手里总拿着一把剪刀”的恐怖人，但最后才知道，阿瑟其实是一个最善良的人，他偷偷地送给孩子们礼物，而且还在危急关头救了斯库特兄妹。他把自己关在屋子里，只因为20年前他闯下一桩祸事，如今他只想呆在屋子里。

  白人雷蒙德被居民们看作一个酒鬼，整天把威士忌装在袋子里，用两根吸管喝，看起来一副醉醺醺的样子。后来三个孩子才发现，雷蒙德从袋子里喝的其实是可乐，他根本不喝酒，他之所以一直假装“醉醺醺”，只因为他认为这就是他想要的“生活方式”。

  杜博斯太太为了阿蒂克斯替黑人辩护辱骂阿蒂克斯一家，激怒了哥哥杰姆，他一怒之捣坏了杜博斯太太心爱的山茶花。阿蒂克斯让杰姆每晚给杜博斯太太念书以赔罪。杜博斯太太总在杰姆念书的时候，时不时地继续奚落杰姆，恶语抨击阿蒂克斯。等到杜博斯太太去世之后，阿蒂克斯才告诉兄妹俩，杜博斯太太当时正忍受着戒掉吗啡瘾的具大折磨。

  

  书中这一类的情节非常多，

  围绕的就是“同理心”这个主题。

  它教给我们的是：

  1、我们为什么跟某个人（或某类人）相处不好，是因为我们对这个人的行事风格产生了不认同，从而对这个人产生了整体的否定。

  2、要是我们总是站在自己的角度看他人，就很难理解为什么他人会有如此“怪异”的行为；

  3、“站在他人角度”：不是简单地把自己假想为对方，根据自己的经验来推测。而是要“钻进别人的身体里四处游荡”，这意味着，

  你得真正去了解这个人过去的背景和经验。

  倘若你还是只以自己的经验去评判这个人的所做所为，是无法实现真正的换位的。

  4、要是你还没有办法“钻进别人的身体里四处游荡”，

  至少，你应该对他人持有这样一个信念：

  “在你最终了解他们之后，你会发现，

  绝大多数人都是好人

  ”。这句话是本书中父亲阿蒂克斯告诉斯科特的最后一句话，我觉得简直是至理名言。在我们还没能了解别人之前，我们至少可以先明白

  “他人的所作所为，都是有理由的”

  。

  如何对待异见？

  你处理“异见”的方式，体现了真正的教养

  自从阿蒂克斯成为黑人汤姆辩护律师后，遭受到镇上很多人的反对和嘲笑。甚至是他的妹妹亚历山德拉，在斯库特看来，亚历山德拉姑妈老派守旧，不仅强制性地要求自己做淑女，而且跟着外人一起对爸爸阿蒂克斯说三道四。斯库特愤怒地反抗亚历山德拉姑妈。但阿蒂克斯却说：“你可以选择自己的朋友，但你不该也无法选择自己的家庭。无论你是否对家人心存感激，家人一直都是你的牵绊。而当你对家庭丧失感激之情时，会让你看上去很愚蠢。”

  另一个激烈反对阿蒂克斯黑人辩护的是杜博斯太太，她总是找切机会谩骂律师一家，后来哥哥杰姆愤怒火山般爆发，把杜博斯院内山茶花头全部打断。阿蒂克斯没有生气，但是坚决地要求他去向杜博斯太太道歉，并在一个月里，每天为她读书两小时做为补偿。一个多月后，杜博斯太太自然死亡，阿蒂克斯告诉孩子们，杜博斯太太为了戒掉吗啡，每天都承受着具大的痛苦，但她一直坚持到了最后，所以如她所愿，她死时无所依赖，完全自由。随后阿蒂克斯对儿子说：

  "即使你没有做那些恶作剧，我也一样会让你去给杜博斯太太读书陪伴她的，因为我希望你好好地看看她。这

  是我见过的最勇敢的人，她诠释了什么叫做真正的勇气。勇

  气不是关于一个男人手里拿着一把枪。勇气是当你走上场之前你就知道你会被痛揍一顿，但是你还是上了场，并且不管发生什么，你坚持到了最后。大部分的时候你都会失败，但有时，你也会成功。"

  

  对黑人汤姆强奸案的审判在小镇上公开举行，三个孩子偷偷混着观礼台上观看审判。控方律师吉尔默恶狠狠地盘问汤姆，令迪尔非常难过，他当场就哭了起来，哥哥杰姆只好把迪尔带出去，

  杰姆告诉迪尔：“那是他的工作啊！没有起诉人，我们就不会有辩护律师了。他理所当然地要用那种神气说话，迪尔，他是在盘问……”

  杰姆小小年纪，已经懂得了把事和人区分开。

  我们需要花多少年，才能学会对事不对人？

  一个人处理“异见”的方式，怎样对待不同观点的人，才真正地体现了教养。

  如何坚持自己？

  在你学会与别人相处之前，要先学会与自己相处

  阿蒂克斯决定为黑人汤姆辩护，在当时的小镇上，遭遇了巨大的非议。阿蒂克斯清楚汤姆是被冤枉的，他跟弟弟赫克这样说：“有时候，我觉得自己做家长很失败，可是我就是他们拥有的一切。在杰姆仰视别人的时候，他首先仰视的是我，我希望自己正直地活着，以便能坦然面对他……”

  

  阿蒂克斯还这样教育两兄妹：

  “你在学校里可能会听到一些不好的议论，不过请你为我做一件事：抬起头，放下拳头。不管别人对你说什么，都不要发火。试着用头脑去抗争。 不能因为我们在此之前已经失败了一百年，就认为我们没有理由去争取胜利”。

  “要在卑劣的事情上保持理智，等事情过去后，便可以带着同情和理解回顾，会因为当时并沒有使人失望而心怀感激。 当大部份人认为他們是对、而你是错，他们当然有权这样认为，他們的观点也有权受到完全的尊重。

  但在能和別人相处之前，首先要和相处。有一种东西不能遵循从众原则，那就是人的良心。”

  由于阿蒂克斯晚婚，在斯库特兄妹的同学中，父亲算太老了（50岁）。兄妹两一直觉得父亲没什么厉害之处，后来无意中得之父亲居然是镇上有名的神枪手。斯库特很着急地想要告诉自己的同学们，可是杰姆却说：“如果他想让我们知道，或者为这个感到骄傲，他早就告诉我们了。阿蒂克斯确实老了，但是，即使他什么都不会干，我也不在乎——阿蒂克斯是个有教养的人，是个真正的绅士。

  

  在经历过一系列的事件后，杰姆终于明白了父亲所说的：

  “勇敢并不是一个人手中拿着枪，而是当你还未开始就已知道自己会输，可你依然要去做，而且无论如何都要将它坚持到底。你很少能赢，但有时也会。”

  揽镜自照

  在学校斯库特的老师盖茨小姐和他们讲了希特勒对待犹太人的残暴行径，讲了“人人平等，没有特权。”可是斯库特却想起审判黑人汤姆有罪那天发生的事，她告诉杰姆：

  “呃，那天晚上从法院出来，盖茨小姐——她下台阶时走在我们前面，你肯定没看见她——她在和斯蒂芬森小姐说话。我听见她说：是该教训教训他们了，他们越来越不知道自己的身份，下一步他们是不是会以为能和我们通婚了。杰姆，一个那么痛恨希特勒的人，怎么转过脸来就对家乡人这么狠毒呢？”

  读到这一段感觉作者真是犀利，揽镜自照一下，自己也常常会犯下盖茨小姐一样的错误，采用自相矛盾的多重标准，然而，当我们的行为与价值观不一致时，就会被孩子一眼看穿。

  

  要是你没有功夫读书，那么就看看电影吧！同名电影是由大名鼎鼎的格里高利·派克主演（主演《罗马假日》的那位），他扮演父亲阿蒂克斯，由于他的精彩演绎，夺得了当年的奥斯卡最佳男主角奖。

  钱穆先生说：我们读好的文学作品，其实是在仰望一个更高的人生，接触合乎自己喜好而境界更高的性格。

  阿蒂克斯是好父母的榜样，等我的孩子大一点，我一定会推荐他读这本《杀死一只知更鸟》，而且告诉他，“这就是我很努力想成为的样子”！

  

  没有人是独立存在在这世间的个体，奇妙的人际充斥着你生命的每一个角落。即便是夜深人静你独自躺在床上的时候，你难道不曾想起——今早邻居狠狠的摔门到底是不是在针对你，午休时同事帮你泡了杯热茶你竟然忘了道谢，下班路上不小心撞到你却没有道歉的少女真是没礼貌……这些，你一定都曾想起！而这些后知后觉的疑惑、懊恼、耿耿于怀，正是人际管理能力的体现！

  这世上没有那么多的高山流水遇知音，一切心有灵犀都是相处的结局，邻居没有摔门，只是因为风大；同事不会因为你没说谢谢就对你有看法；撞到你的少女家里出了急事才导致她如此慌乱……拥有更好的人际觉察力和理解力，真正让自己舒服，也让他人舒服。永不恶言相向，永不暗自考量，永不放任乖张，永不停止生长……

  愿这个城市里处处都有你的朋友，每敲开一扇房门，都会有热情的笑脸相迎！

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