市场竞争中，经常遇到的一个问题是，为什么我的产品不比对手差，我提供的服务也有优势，但用户还是集中在对手哪里？ 如果不是高估了自己产品和服务的话，那么，很有可能，是因为你没有把握到意见领袖。
意见领袖，其实含义很简单，是能够影响更多人决策的那些人，但具体理解上，很多人会犯一个简单的错误，误以为意见领袖就是大V。
大V可以认为是意见领袖，但不代表全部，实际上，意见领袖的涵盖有更广的范畴，在某些领域，甚至大V未必是最管用的意见领袖。
游戏领域，比如一些工会的会长是典型的意见领袖，这也带来了一堆的商业模式，之前两个网友的投稿文章都有提及。某些消费领域，可能广场舞的大妈就是意见领袖，千万不要小看这些邻里的信息传播力；
而某些to b的领域，一些典型的行业领先者，即便他们从不发声，从不宣扬，但他们的行为本身，很可能也构成意见领袖的效果。
我举个简单例子，比如，李兴平，从来不写文章，从来不接受采访，你基本上在任何媒体上都看不到他的消息，但时间放十几年前，很多优秀的草根站长都会盯着他的网站去分析，去看，如果有一天，某个第三方服务的代码在他的网站上出现了，立即就会有示范作用，很多其他草根站长就会跟进去使用，这种无声胜有声，也是意见领袖的价值。
我再举个简单例子，
比如去年遇到一个做Facebook投放优化的跨国企业，那么这公司背景当然可以搜搜谷歌，可以看看官网，但这玩意说实话，有几分可信呢，去跟对方聊天，很简单，你典型客户是谁，结果一看，我们同行中的某个领先者是他们典型客户，基本所有投放都是委托他们负责的，这我就觉得有价值了，就可以看能不能深入合作了。道理很简单，人家做的那么成功的公司都用了他们服务，这个信任关系就容易建立了。行业典型客户，就比广告，大V背书更管用。
大V背书是拿人家钱说人家好话，而典型的行业客户是人家花钱来用这个产品和服务，那么你觉得哪个可信，肯定是典型行业客户对吧。比如说，我或者其他哪个大V推荐说，某某云的服务不错哎，你可能信，也可能觉得，这是拿了人家钱了，但如果你发现，哎呦，原来你们所处行业的领先者用了这个云服务，这就比我，或者其他大V背书更可信。
媒体属性的产品，比如新浪微博是典型的抓大V战略，当年新浪博客战胜博客中国的时候，也是同一个路数。但到了快手这种产品，意见领袖就不是传统意义的大V了，可能一些群主，一些社区版主就成为意见领袖了。更多大V解读：www.yangfenzi.com/tag/dav
to b属性的，行业代表客户就是意见领袖，我以前提过我的创业历史，从广告交换到网站统计，都是一个路数，典型的站长使用了我们的产品，很多其他站长就跟风加入了。做广告交换的时候，我用了很土，但当时很有效的一个方法，我当时通过网易的易数统计，打开排名前100的个人网站，挨个寻找联系方式，去发邮件，其实就发了一百封的样子，每一封都是针对对方网站的主题，内容，去发的，绝对不是群发。那么回复率呢，说实话，那是十六七年前，邮件还是有人看的，不能说有效率很高，百分之五总有吧。然后有几个顶部网站加入了我的交换平台，他们网站上有了我的代码，很多其他网站就跟进，也就一个礼拜的时间，整个系统的请求规模就爆发了。 当然这个方法现在已经很难复制了，因为垃圾邮件泛滥，大家已经没心思看具体邮件内容了，但可以作为参考。当年cnzz能爆发，也是跟一些顶级网站开始使用的示范效应有关。
那么，今天讲的这些，估计有些人觉得，好像都是大家都知道的，有什么可讲的。是的，说出来很多人都觉得没什么，但怎么做，能否做得到，很多创业者都会犯错误。
第一，关于产品的种子用户培养
我以前说过，不要试图讨好所有人，要找核心用户，核心用户是什么，就是能代表核心诉求，并且具有影响力的那批用户，让他们对你的产品满意，这个才会产生口碑和传播效应。
我最近遇到一些做企业软件的创业者，他们分享的一个非常重要的，具有共性的事实就是，发展第一个用户是最难的，因为你没有案例，没有示范作用，纯粹用自己的产品说话，人家很难形成信任；但一旦获得典型用户，获得一个行业内公认的企业用户，后续的业务拓展就会简单的多。
百度电商的尝试，百度有啊 当年做的很失败，后来私下复盘的时候，有个老百度总监的一个观点我是认同的，百度的流量资源并没有自己想象的那么好，当时的投入又有限，与其大锅饭一样的疯狂发展中小商家，不如把流量集中起来，主要扶植和培养少数典型商家，百度还是有足够资源，可以让部分商家赚到钱，获得持续运作的信心，这样形成口碑积累，再基于这样的示范作用，慢慢扩展，可能机会还是有的。
让你的种子用户跟你合作能赚钱，或者有正收益，能有示范作用，比一下子努力发展很多用户更重要。
第二，营销拓展的手段，要迎合意见领袖的口味
这个我认为是很多企业所忽视的问题，比如说很多餐厅说，你分享朋友圈或微博，一个图片，一段文字，我给你一个免费饮料，那么，就算我觉得他们好吃，我也不会分享，为什么呢？让人觉得我为一个免费饮料去分享，是不是太low了？我要是说句不客气的，让我分享一下朋友圈、微博，你餐厅给我免单都不算过份吧。 所以很多这种所谓的传播活动，通常无法吸引到意见领袖的参与。
很多类似这样的分享活动，包括一些微博活动，都没有考虑到意见领袖的心理诉求和动机。虽然我们现在说，雕爷牛腩只有营销做得好，产品实在不好吃，但从营销来说，人家早期真真正正抓住多少意见领袖。意见领袖最爱分享的是什么，是稀缺啊，独享啊！逼格满满啊！（当然他们未必承认）
我知道有些草根营销大号，其实是很深入的分析和整理过一些顶部明星大V的转发习惯和品味，然后有相当多内容其实是有针对性的，当然，你不能说他们这样做每次都有效果，但是这样的准备多了，总会有被大V转发的机会，只要做到位，100篇获得1篇大V转发，都会获得很好的效果。
第三，品牌露出！品牌露出！品牌露出！
重要的话说三遍，比如有一些典型企业客户使用了你们的产品，尽量要让终端用户或行业客户看到你们品牌 。
前文提到，对于企业级产品来说，典型客户是意见领袖，但不代表你做了他们的生意，就会有示范作用，一定要让你的品牌，在这个合作中，显露出来。（Google Analytics可以没有品牌露出，因为人家牛逼，但cnzz初期是一定要品牌露出的。访问者基本不会关心这个，但同行站长一定会看到！）
比如现在比较流行的，餐厅的综合收帐系统，支付宝，微信支付，银行卡集中结算的平台，最近几年好多家竞争，那么在用户付费的地方，很多都有自己的品牌露出，你说消费者会关心么，绝大部分都不关心，这不重要。但同行会关心，同行也经常去对方店里消费，学习对不对，对这种细节就会特别在意，这个示范作用就起来了。
所以，把握意见领袖，不是说你服务好他就够了，还要让他有示范作用。
第四，利用激励途径吸引意见领袖也已经成为一种商业模式。
比如：我们说，游戏代充套利，游戏放端套利里提到的，做工会，这个就是一种以意见领袖为商业模式的营销玩法。
比如：拼团现在很流行，也可以认为是用激励一些意见领袖，积极发展终端用户的一种模式。
在这里，我们看到的很多意见领袖，未必是那些所谓的大V和知名人士，很多就是在邻里比较活络的人，比如广场舞大妈；也有一些在网上比较活跃的人，比如一些吧主，群主。但这里有一个重要的因素，就是他们不但有足够的社交面，还在他们的社交圈里有一定的公信力，有些职业的人社交面很广，但公信力未必够，比如一些经纪人和销售代表。
第五，要重视意见领袖的反馈和意见
好像这是废话，但很多社区会说，我们要对用户一视同仁，不能说意见领袖就一定是对的。这个说法没错，不过有一点是不公平的。
比如知乎，一个有很多粉丝的用户，和一个三无用户，谁会更在意自己的品牌和口碑，如果三无用户开撕，各种恶言相向，他们其实对处罚无所谓，被封号再换一个，毫无压力，甚至开七八个小号来撕逼。那么大V呢，只能打不还手骂不还口么？看上去公平的处罚策略，在这里其实已经不公平了对不对。
所以，要把握这里的平衡，并不是说意见领袖一定是对的，但是你要知道一点，就是在社区里，通常，意见领袖相比于其他普通用户，更容易成为标靶，更容易受到伤害。
话说，如果微信对公众号大V评论回复做友好度判定，我估计很多知名大V都要被封了。
第六，产品和服务做的足够好，意见领袖有可能成为自来水。
这是一句政治正确的话，但确实我也看到很多这样的案例。比如nestia获得新加坡第一夫人的推广，比如当年厦门一个视频工具，“小偶”在全球的意外爆发（横扫包括美日韩等主流发达国家，几十个国家免费榜单榜首），都是类似。（知乎上有小偶爆发的问答贴，有兴趣的自己搜索，依靠意见领袖迅速蹿红的一个经典案例，不过今年有点销声匿迹了）
那么，也是同样基于小偶这样的案例，务必再提醒创业者一句，即便你把握到了意见领袖，如果后续的产品和服务，以及商业模式，没能保持在高水准上，或者缺乏持续性，很可能你的成功也会转瞬而逝。 这又是一句政治正确的言论，但真的很多案例都在，包括雕爷牛腩，黄太吉煎饼，也都是曾经为意见领袖追捧，而今乏人问津。
所以，把握意见领袖，是创业者需要学习和思考的一个问题，但不是全部。
知乎一篇问题分享，答应读者，一直没想起来的。
标题：有哪些看起来很高端的技术其实原理很暴力很初级？
链接：https://www.zhihu.com/question/33634376
分享理由：
其中几个游戏研发的案例，是我要求我的工程师务必学习的。
比如，魔兽世界的兔子，孤单枪手的设计，辐射3的火车头。
为什么要学习呢，就是复用思维，将一些复杂的场景诉求，用简单的技术方案实现，在结构上极大简化开发难度和开发成本。
产品诉求，A是A，B是B，C是C，但从实现机制来说，有没有可能用统一结构和逻辑来支持，以较小的开发成本和资源开销，完成看上去复杂的场景诉求，这很可能就是竞争力。
另外，这两天热点话题，Gitlab 被误操作，数据库丢失，我找了找有篇旧文可以应景
创业公司如何做好信息安全(下)
这里提到了备份的策略和注意事项，但回顾旧文的时候，不由得感慨一下，乌云已经被关了很久了，其创始人方小顿，目前依然无法联系。。。
没有乌云，天就一定晴了么
【文/曹政 “caoz 的梦呓”（微信号：caozsay）】
——————— 氧分子网（www.yangfenzi.com）精选评论 ———————
任易：感谢曹总分享，获得的最有用的信息是对公信力的分析。无论行业标杆客户，还是草根站长的标杆，还是广场舞领队，局头，他们才是有公信力的一方。传播渠道和公信力相比，我会选择慢慢累积公信力，非常感谢！祝新年快乐！白猫：我在想如果曹老师把自己文章的内容做成五分钟视频，放在美拍等新媒体运营上，会是什么感觉？万花丛中一点绿？总感觉短视频已经打上娱乐的标签了，但是罗胖做视频抓住人买书门槛低读书门槛高的特性倒是忽悠了一堆假努力的人。
曾剑锋：很久以前观察到这种现象，没总结出这四个字，很关键的四个字，get到了。马太闹：感觉大V的最大作用在于，在认可了这个人的专业及领域之后普通人可以少很多的不必要的决策成本，比如什么领域的哪款app最好用，吃什么馆子等等诸如此类懒得仔细研究的领域。意见领袖的核心价值就是帮有需要的人节省了时间吧。
刘杨：美国的很多服装品牌被第一夫人或明星穿过后就一夜爆红或者销量大增。国内好多网红也在卖衣服。恭喜发才：话说微信为什么没有夜读功能？好像和曹大的文章不对题，但是我以前真的向微信团队提过建议，可能是因为不是意见领袖得不到重视。木白的真名是徐乐：to B行业，创业者是不是应该向标杆客户提供相对排他性的价格，服务，和产品呢？我今年经历的一家公司，老板在技术领域无比牛，说花名可能曹大会知道。可是不知道为何，我们和一个行业内的标杆企业谈了将近2年没有落实到执行。求解！
睡猫逍遥（杭沪）：深深感受到知识鸿沟的存在。获取信息能力强、对网络怀有好奇心和热情的人往往比他人更早的接受网络，把握网络。举个例子，在微博刚刚出现的时候，就有人意识到可以做意见领袖、网络大V，而在我，则是社交、娱乐、查阅信息的途径而已。深感自己意识落后到什么地步了。第一，要整合不要孤立，不要为微博而微博。第二，内容为王，与粉丝兴趣相契合。第三，抓意见领袖，事半功倍。第四，把握好时间点，有效互动。第五，结合移动，放大即时效益。第六，在微博上主动聆听。【舆情分析四境界】1.窥物，使用常见工具和方法，梳理观点，点出舆论对攻点，给出初步预测和应对方案；2.窥景，对主要媒体、意见领袖、网民心态和线下公众情绪有把握，宏观认知真实舆论背景；3.窥势，了解发现新的舆论规律，运动方向。4.窥道，从各学科观察舆论，了解舆论和社会运动的关系及影响走势。
张小河：海棠前端专注在线教育，产品好（不是盲目自夸），没太多钱做付费推广，面向的群体也都是小白用户偏多。如何低成本让意见领袖代发言呢？感谢，已打赏。M.ay0o_流星：意见领袖确实很重要，toB的标杆客户，toC的大V传播和口碑引流；btw，没有了乌云，我们所能看到的也未必是晴天，前员工留。张兆超：《引爆点》中也有类似的观点，必须要承认不同的人的社交影响力是不一样的。曹大从几种不同的人群进行划分，读完有新收获。
许毅松：分享一个小案例，去年刚毕业做过一阵少儿编程培训班，这种教育项目招生最有效的方式之一就是邀请家长参加体验课，大家平时在地铁站可能都会碰到各种邀请参加英语体验课的，都是一样的路数，我们每周都会举办体验课，但怎么吸引到足够多的家长参加就是问题了，来一个家长和来十个家长成本是差不多的（场地，讲师等）为了让同一时间有更多家长参加，每次有家长打电话联系时我都会多问一句“我们体验课要达到6个人才能开办，您能不能问一下您身边的其他家长朋友来不来参加？”，一般来说有不少家长都会不愿意，但有一些时候就会碰到一些意见领袖家长，平时就是各种活动的组织者，可以把他身边的家长朋友都带过来，这种情况下我们体验课开办就很容易了。
·氧分子网（http://www.yangfenzi.com）综合整理报道
·氧分子网（http://www.yangfenzi.com）延伸阅读：
➤ 马化腾两会提案：关注分享经济和互联网医疗、互联网生态安全
2017年1月31日晚上，GitLab通过Twitter发文承认300GB生产环境数据因为UNIX 运维的误操作，已经被彻底删除，后补充说明已挽回大部分数据，并开启直播，将恢复工作全部公开，也是尽职尽责。社群群中也有很多同学做了讨论，陈皓在文章中亦做了深入思考与总结。
群里有人说，rm之前要看pwd的，然后有同学接着说，pwd还不够，还要看哪台机器上。
以下为文章正文。
昨天，GitLab.com发生了一个大事，某同学误删了数据库，这个事看似是个低级错误，不过，因为GitLab把整个过程的细节都全部暴露出来了，所以，可以看到很多东西，而对于类似这样的事情，我自己以前也干过，而在最近的两公司中我也见过（Amazon中见过一次，阿里中见过至少四次），正好通过这个事来说说一下自己的一些感想和观点吧。
我先放个观点：你觉得有备份系统就不会丢数据了吗？
事件回顾
整个事件的回顾GitLab.com在第一时间就放到了Google Doc上，事后，又发了一篇Blog来说明这个事，在这里，我简单的回顾一下这个事件的过程。
首先，一个叫YP的同学在给GitLab的线上数据库做一些负载均衡的工作，在做这个工作时的时候突发了一个情况，GitLab被DDoS攻击，数据库的使用飙高，在block完攻击者的IP后，发现有个staging的数据库(db2.staging)已经落后生产库4GB的数据，于是YP同学在Fix这个staging库的同步问题的时候，发现db2.staging有各种问题都和主库无法同步，在这个时候，YP同学已经工作的很晚了，在尝试过多个方法后，发现db2.staging都hang在那里，无法同步，于是他想把db2.staging的数据库删除了，这样全新启动一个新的复制，结果呢，删除数据库的命令错误的敲在了生产环境上（db1.cluster），结果导致整个生产数据库被误删除（陈皓注：这个失败基本上就是 “工作时间过长” + “在多数终端窗口中切换中迷失掉了”）。
在恢复的过程中，他们发现只有db1.staging的数据库可以用于恢复，而其它的5种备份机制都不可用，第一个是数据库的同步，没有同步webhook，第二个是对硬盘的快照，没有对数据库做，第三个是用pg_dump的备份，发现版本不对（用9.2的版本去dump 9.6的数据）导致没有dump出数据，第四个S3的备份，完全没有备份上，第五个是相关的备份流程是问题百出的，只有几个粗糙的人肉的脚本和糟糕的文档，也就是说，不但是是人肉的，而且还是完全不可执行的（注：就算是这些备份机制都work，其实也有问题，因为这些备份大多数基本上都是24小时干一次，所以，要从这些备份恢复也一定是是要丢数据的了，只有第一个数据库同步才会实时一些）。
最终，GitLab从db1.staging上把6个小时前的数据copy回来，结果发现速度非常的慢，备份结点只有60Mbits/S，拷了很长时间（陈皓注：为什么不把db1.staging给直接变成生产机？因为那台机器的性能很差）。数据现在的恢复了，不过，因为恢复的数据是6小时前的，所以，有如下的数据丢失掉了：
粗略估计，有4613 的项目， 74 forks, 和 350 imports 丢失了；但是，因为Git仓库还在，所以，可以从Git仓库反向推导数据库中的数据，但是，项目中的issues等就完全丢失了。
大约有±4979 提交记录丢失了（陈皓注：估计也可以用git仓库中反向恢复）。
可能有 707 用户丢失了，这个数据来自Kibana的日志。
在1月31日17:20 后的Webhooks 丢失了。
因为GitLab把整个事件的细节公开了出来，所以，也得到了很多外部的帮助，2nd Quadrant的CTO – Simon Riggs 在他的blog上也发布文章 Dataloss at GitLab 给了一些非常不错的建议：
关于PostgreSQL 9.6的数据同步hang住的问题，可能有一些Bug，正在fix中。
PostgreSQL有4GB的同步滞后是正常的，这不是什么问题。
正常的停止从结点，会让主结点自动释放WALSender的链接数，所以，不应该重新配置主结点的 max_wal_senders 参数。但是，停止从结点时，主结点的复数连接数不会很快的被释放，而新启动的从结点又会消耗更多的链接数。他认为，GitLab配置的32个链接数太高了，通常来说，2到4个就足够了。
另外，之前GitLab配置的max_connections=8000太高了，现在降到2000个是合理的。
pg_basebackup 会先在主结点上建一个checkpoint，然后再开始同步，这个过程大约需要4分钟。
手动的删除数据库目录是非常危险的操作，这个事应该交给程序来做。推荐使用刚release 的 repmgr。
恢复备份也是非常重要的，所以，也应该用相应的程序来做。推荐使用 barman （其支持S3）。
测试备份和恢复是一个很重要的过程。
看这个样子，估计也有一定的原因是——GitLab的同学对PostgreSQL不是很熟悉。
随后，GitLab在其网站上也开了一系列的issues，其issues列表在这里 Write post-mortem (这个列表可能还会在不断更新中)。
infrastructure#1094 – Update PS1 across all hosts to more clearly differentiate between hosts and environments
infrastructure#1095 – Prometheus monitoring for backups
infrastructure#1096 – Set PostgreSQL’s max_connections to a sane value
infrastructure#1097 – Investigate Point in time recovery & continuous archiving for PostgreSQL
infrastructure#1098 – Hourly LVM snapshots of the production databases
infrastructure#1099 – Azure disk snapshots of production databases
infrastructure#1100 – Move staging to the ARM environment
infrastructure#1101 – Recover production replica(s)
infrastructure#1102 – Automated testing of recovering PostgreSQL database backups
infrastructure#1103 – Improve PostgreSQL replication documentation/runbooks
infrastructure#1104 – Kick out SSH users inactive for N minutes
infrastructure#1105 – Investigate pgbarman for creating PostgreSQL backups
从上面的这个列表中，我们可以看到一些改进措施了。挺好的，不过我觉得还不是很够。
因为类似这样的事，我以前也干过（误删除过数据库，在多个终端窗口中迷失掉了自己所操作的机器……），而且我在亚马逊里也见过一次，在阿里内至少见过四次以上（在阿里人肉运维的误操作的事故是我见过最多的），但是我无法在这里公开分享，私下可以分享。在这里，我只想从非技术和技术两个方面分享一下我的经验和认识。
我的思考：技术方面
人肉运维
一直以来，我都觉得直接到生产线上敲命令是一种非常不好的习惯。我认为，一个公司的运维能力的强弱和你上线上环境敲命令是有关的，你越是喜欢上线敲命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。理由如下：
如果说对代码的改动都是一次发布的话，那么，对生产环境的任何改动（包括硬件、操作系统、网络、软件配置……），也都算是一次发布。那么这样的发布就应该走发布系统和发布流程，要被很好的测试、上线和回滚计划。关键是，走发布过程是可以被记录、追踪和回溯的，而在线上敲命令是完全无法追踪的。没人知道你敲了什么命令。
真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。你敲了什么命令没人知道，但是你写个工具做变更线上系统，这个工具干了什么事，看看工具的源码就知道了。
另外，有人说，以后不要用rm了，要用mv，还有人说，以后干这样的事时，一个人干，另一个人在旁边看，还有人说，要有一个checklist的强制流程做线上的变更，还有人说要增加一个权限系统。我觉得，这些虽然可以work，但是依然不好，因为：
如果要解决一个事情需要加更多的人来做的事，那这事就做成劳动密集型了。今天我们的科技就是在努力消除人力成本，而不是在增加人力成本。而做为一个技术人员，解决问题的最好方式是努力使用技术手段，而不是使用更多的人肉手段。人类区别于动物的差别就是会发明和使用现代化的工具，而不是使用更多的人力。另外，这不仅仅因为是，人都是会有这样或那样的问题（疲惫、情绪化、急燥、冲动……），而机器是单一无脑不知疲惫的，更是因为，机器干活的效率和速度是比人肉高出N多倍的。
增加一个权限系统或是别的一个watch dog的系统完全是在开倒车，权限系统中的权限谁来维护和审批？不仅仅是因为多出来的系统需要多出来的维护，关键是这个事就没有把问题解决在root上。除了为社会解决就业问题，别无好处，故障依然会发生，有权限的人一样会误操作。对于GitLab这个问题，正如2nd Quadrant的CTO建议的那样，你需要的是一个自动化的备份和恢复的工具，而不是一个权限系统。
像使用mv而不rm，搞一个checklist和一个更重的流程，更糟糕。这里的逻辑很简单，因为，1）这些规则需要人去学习和记忆，本质上来说，你本来就不相信人，所以你搞出了一些规则和流程，而这些规则和流程的执行，又依赖于人，换汤不换药，2）另外，写在纸面上的东西都是不可执行的，可以执行的就是只有程序，所以，为什么不把checklist和流程写成代码呢（你可能会说程序也会犯错，是的，程序的错误是consistent，而人的错误是inconsistent）？
最关键的是，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些想流程、规则、人肉检查、权限系统、checklist等等统统都不管用了，这个时候，你觉得应该怎么做呢？是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统！别无它法。
关于备份
一个系统是需要做数据备份的，但是，你会发现，GitLab这个事中，就算所有的备份都可用，也不可避免地会有数据的丢失，或是也会有很多问题。理由如下：
备份通常来说都是周期性的，所以，如果你的数据丢失了，从你最近的备份恢复数据里，从备份时间到故障时间的数据都丢失了。
备份的数据会有版本不兼容的问题。比如，在你上次备份数据到故障期间，你对数据的scheme做了一次改动，或是你对数据做了一些调整，那么，你备份的数据就会和你线上的程序出现不兼容的情况。
有一些公司或是银行有灾备的数据中心，但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候，你就会发现，各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴，宁夏银行7月系统瘫痪最新解析》。
所以，在灾难来临的时候，你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作，但也会导致数据丢失，而且可能长期不用的备份系统很难恢复（比如应用、工具、数据的版本不兼容等问题）。
我之前写过一篇《分布式系统的事务处理》，你还记得下面这张图吗？看看 Data Loss 那一行的，在Backups, Master/Slave 和 Master/Master的架构下，都是会丢的。
所以说，如果你要让你的备份系统随时都可以用，那么你就要让它随时都Live着，而随时都Live着的多结点系统，基本上就是一个分布式的高可用的系统。因为，数据丢失的原因有很多种，比如掉电、磁盘损坏、中病毒等等，而那些流程、规则、人肉检查、权限系统、checklist等等都只是让人不要误操作，都不管用，这个时候，你不得不用更好的技术去设计出一个高可用的系统！别无它法。（重要的事，得再说一篇）
另外，你可以参看我的另一篇《关于高可用系统》，这篇文章中以MySQL为例，数据库的replication也只能达到 两个9。
AWS 的 S3 的的高可用是4个加11个9的持久性（所谓11个9的持久性durability，AWS是这样定义的，如果你存了1万个对象，那么丢一个的时间是1000万年），这意味着，不仅仅只是硬盘坏，机器掉电，整个机房挂了，其保证可以承受有两个设施的数据丢失，数据还是可用的。试想，如果你把数据的可用性通过技术做到了这个份上，那么，你还怕被人误删一个结点上的数据吗？
我的思考：非技术方面
故障反思
一般说来，故障都需要反思，在Amazon，S2以上的故障都需要写COE（Correction of Errors），其中一节就是需要Ask 5 Whys，我发现在GitLab的故障回顾的blog中第一段中也有说要在今天写个Ask 5 Whys。关于Ask 5 Whys，其实并不是亚马逊的玩法，这还是算一个业内常用的玩法，也就是说不断的为自己为为什么，直到找到问题的概本原因，这会逼着所有的当事人去学习和深究很多东西。在Wikipedia上有相关的词条 5 Whys，其中罗列了14条规则：
你需要找到正确的团队来完成这个故障反思。
使用纸或白板而不是电脑。
写下整个问题的过程，确保每个人都能看懂。
区别原因和症状。
特别注意因果关系。
说明Root Cause以及相关的证据。
5个为什么的答案需要是精确的。
寻找问题根源的频，而不是直接跳到结论。
要基础客观的事实、数据和知识。
评估过程而不是人。
千万不要把“人为失误”或是“工作不注意”当成问题的根源。
培养信任和真诚的气氛和文化。
不断的问“为什么”直到问题的根源被找到。这样可以保证同一个坑不会掉进去两次。
当你给出“为什么”的答案时，你应该从用户的角度来回答。
工程师文化
上述的这些观点，其实，我在我的以住的博客中都讲过很多遍了，你可以参看《什么是工程师文化？》以及《开发团队的效率》。其实，说白了就是这么一个事——如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。
这个道理很简单，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些流程、规则、人肉检查、权限系统、checklist等等统统都不管用，这个时候，你觉得应该怎么做呢？是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统！别无它法（重要的事得说三遍）。
事件公开
很多公司基本上都是这样的套路，首先是极力掩盖，如果掩盖不了了就开始撒谎，撒不了谎了，就“文过饰非”、“避重就轻”、“转移视线”。然而，面对危机的最佳方法就是——“多一些真诚，少一些套路”，所谓的“多一些真诚”的最佳实践就是——“透明公开所有的信息”，GitLab此次的这个事给大家树立了非常好的榜样。AWS也会把自己所有的故障和细节都批露出来。
事情本来就做错了，而公开所有的细节，会让大众少很多猜测的空间，有利于抵制流言和黑公关，同时，还会赢得大众的理解和支持。看看GitLab这次还去YouTube上直播整个修复过程，是件很了不起的事，大家可以到他们的blog上看看，对于这样的透明和公开，一片好评。
作者：左耳朵耗子，本名陈皓。Coolshell博主。21CTO社区会员。
2017年1月31日晚上，GitLab通过Twitter发文承认300GB生产环境数据因为UNIX 运维的误操作，已经被彻底删除，后补充说明已挽回大部分数据，并开启直播，将恢复工作全部公开，也是尽职尽责。社群群中也有很多同学做了讨论，陈皓在文章中亦做了深入思考与总结。
群里有人说，rm之前要看pwd的，然后有同学接着说，pwd还不够，还要看哪台机器上。
以下为文章正文。
昨天，GitLab.com发生了一个大事，某同学误删了数据库，这个事看似是个低级错误，不过，因为GitLab把整个过程的细节都全部暴露出来了，所以，可以看到很多东西，而对于类似这样的事情，我自己以前也干过，而在最近的两公司中我也见过（Amazon中见过一次，阿里中见过至少四次），正好通过这个事来说说一下自己的一些感想和观点吧。
我先放个观点：你觉得有备份系统就不会丢数据了吗？
事件回顾
整个事件的回顾GitLab.com在第一时间就放到了Google Doc上，事后，又发了一篇Blog来说明这个事，在这里，我简单的回顾一下这个事件的过程。
首先，一个叫YP的同学在给GitLab的线上数据库做一些负载均衡的工作，在做这个工作时的时候突发了一个情况，GitLab被DDoS攻击，数据库的使用飙高，在block完攻击者的IP后，发现有个staging的数据库(db2.staging)已经落后生产库4GB的数据，于是YP同学在Fix这个staging库的同步问题的时候，发现db2.staging有各种问题都和主库无法同步，在这个时候，YP同学已经工作的很晚了，在尝试过多个方法后，发现db2.staging都hang在那里，无法同步，于是他想把db2.staging的数据库删除了，这样全新启动一个新的复制，结果呢，删除数据库的命令错误的敲在了生产环境上（db1.cluster），结果导致整个生产数据库被误删除（陈皓注：这个失败基本上就是 “工作时间过长” + “在多数终端窗口中切换中迷失掉了”）。
在恢复的过程中，他们发现只有db1.staging的数据库可以用于恢复，而其它的5种备份机制都不可用，第一个是数据库的同步，没有同步webhook，第二个是对硬盘的快照，没有对数据库做，第三个是用pg_dump的备份，发现版本不对（用9.2的版本去dump 9.6的数据）导致没有dump出数据，第四个S3的备份，完全没有备份上，第五个是相关的备份流程是问题百出的，只有几个粗糙的人肉的脚本和糟糕的文档，也就是说，不但是是人肉的，而且还是完全不可执行的（注：就算是这些备份机制都work，其实也有问题，因为这些备份大多数基本上都是24小时干一次，所以，要从这些备份恢复也一定是是要丢数据的了，只有第一个数据库同步才会实时一些）。
最终，GitLab从db1.staging上把6个小时前的数据copy回来，结果发现速度非常的慢，备份结点只有60Mbits/S，拷了很长时间（陈皓注：为什么不把db1.staging给直接变成生产机？因为那台机器的性能很差）。数据现在的恢复了，不过，因为恢复的数据是6小时前的，所以，有如下的数据丢失掉了：
粗略估计，有4613 的项目， 74 forks, 和 350 imports 丢失了；但是，因为Git仓库还在，所以，可以从Git仓库反向推导数据库中的数据，但是，项目中的issues等就完全丢失了。
大约有±4979 提交记录丢失了（陈皓注：估计也可以用git仓库中反向恢复）。
可能有 707 用户丢失了，这个数据来自Kibana的日志。
在1月31日17:20 后的Webhooks 丢失了。
因为GitLab把整个事件的细节公开了出来，所以，也得到了很多外部的帮助，2nd Quadrant的CTO – Simon Riggs 在他的blog上也发布文章 Dataloss at GitLab 给了一些非常不错的建议：
关于PostgreSQL 9.6的数据同步hang住的问题，可能有一些Bug，正在fix中。
PostgreSQL有4GB的同步滞后是正常的，这不是什么问题。
正常的停止从结点，会让主结点自动释放WALSender的链接数，所以，不应该重新配置主结点的 max_wal_senders 参数。但是，停止从结点时，主结点的复数连接数不会很快的被释放，而新启动的从结点又会消耗更多的链接数。他认为，GitLab配置的32个链接数太高了，通常来说，2到4个就足够了。
另外，之前GitLab配置的max_connections=8000太高了，现在降到2000个是合理的。
pg_basebackup 会先在主结点上建一个checkpoint，然后再开始同步，这个过程大约需要4分钟。
手动的删除数据库目录是非常危险的操作，这个事应该交给程序来做。推荐使用刚release 的 repmgr。
恢复备份也是非常重要的，所以，也应该用相应的程序来做。推荐使用 barman （其支持S3）。
测试备份和恢复是一个很重要的过程。
看这个样子，估计也有一定的原因是——GitLab的同学对PostgreSQL不是很熟悉。
随后，GitLab在其网站上也开了一系列的issues，其issues列表在这里 Write post-mortem (这个列表可能还会在不断更新中)。
infrastructure#1094 – Update PS1 across all hosts to more clearly differentiate between hosts and environments
infrastructure#1095 – Prometheus monitoring for backups
infrastructure#1096 – Set PostgreSQL’s max_connections to a sane value
infrastructure#1097 – Investigate Point in time recovery & continuous archiving for PostgreSQL
infrastructure#1098 – Hourly LVM snapshots of the production databases
infrastructure#1099 – Azure disk snapshots of production databases
infrastructure#1100 – Move staging to the ARM environment
infrastructure#1101 – Recover production replica(s)
infrastructure#1102 – Automated testing of recovering PostgreSQL database backups
infrastructure#1103 – Improve PostgreSQL replication documentation/runbooks
infrastructure#1104 – Kick out SSH users inactive for N minutes
infrastructure#1105 – Investigate pgbarman for creating PostgreSQL backups
从上面的这个列表中，我们可以看到一些改进措施了。挺好的，不过我觉得还不是很够。
因为类似这样的事，我以前也干过（误删除过数据库，在多个终端窗口中迷失掉了自己所操作的机器……），而且我在亚马逊里也见过一次，在阿里内至少见过四次以上（在阿里人肉运维的误操作的事故是我见过最多的），但是我无法在这里公开分享，私下可以分享。在这里，我只想从非技术和技术两个方面分享一下我的经验和认识。
我的思考：技术方面
人肉运维
一直以来，我都觉得直接到生产线上敲命令是一种非常不好的习惯。我认为，一个公司的运维能力的强弱和你上线上环境敲命令是有关的，你越是喜欢上线敲命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。理由如下：
如果说对代码的改动都是一次发布的话，那么，对生产环境的任何改动（包括硬件、操作系统、网络、软件配置……），也都算是一次发布。那么这样的发布就应该走发布系统和发布流程，要被很好的测试、上线和回滚计划。关键是，走发布过程是可以被记录、追踪和回溯的，而在线上敲命令是完全无法追踪的。没人知道你敲了什么命令。
真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。你敲了什么命令没人知道，但是你写个工具做变更线上系统，这个工具干了什么事，看看工具的源码就知道了。
另外，有人说，以后不要用rm了，要用mv，还有人说，以后干这样的事时，一个人干，另一个人在旁边看，还有人说，要有一个checklist的强制流程做线上的变更，还有人说要增加一个权限系统。我觉得，这些虽然可以work，但是依然不好，因为：
如果要解决一个事情需要加更多的人来做的事，那这事就做成劳动密集型了。今天我们的科技就是在努力消除人力成本，而不是在增加人力成本。而做为一个技术人员，解决问题的最好方式是努力使用技术手段，而不是使用更多的人肉手段。人类区别于动物的差别就是会发明和使用现代化的工具，而不是使用更多的人力。另外，这不仅仅因为是，人都是会有这样或那样的问题（疲惫、情绪化、急燥、冲动……），而机器是单一无脑不知疲惫的，更是因为，机器干活的效率和速度是比人肉高出N多倍的。
增加一个权限系统或是别的一个watch dog的系统完全是在开倒车，权限系统中的权限谁来维护和审批？不仅仅是因为多出来的系统需要多出来的维护，关键是这个事就没有把问题解决在root上。除了为社会解决就业问题，别无好处，故障依然会发生，有权限的人一样会误操作。对于GitLab这个问题，正如2nd Quadrant的CTO建议的那样，你需要的是一个自动化的备份和恢复的工具，而不是一个权限系统。
像使用mv而不rm，搞一个checklist和一个更重的流程，更糟糕。这里的逻辑很简单，因为，1）这些规则需要人去学习和记忆，本质上来说，你本来就不相信人，所以你搞出了一些规则和流程，而这些规则和流程的执行，又依赖于人，换汤不换药，2）另外，写在纸面上的东西都是不可执行的，可以执行的就是只有程序，所以，为什么不把checklist和流程写成代码呢（你可能会说程序也会犯错，是的，程序的错误是consistent，而人的错误是inconsistent）？
最关键的是，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些想流程、规则、人肉检查、权限系统、checklist等等统统都不管用了，这个时候，你觉得应该怎么做呢？是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统！别无它法。
关于备份
一个系统是需要做数据备份的，但是，你会发现，GitLab这个事中，就算所有的备份都可用，也不可避免地会有数据的丢失，或是也会有很多问题。理由如下：
备份通常来说都是周期性的，所以，如果你的数据丢失了，从你最近的备份恢复数据里，从备份时间到故障时间的数据都丢失了。
备份的数据会有版本不兼容的问题。比如，在你上次备份数据到故障期间，你对数据的scheme做了一次改动，或是你对数据做了一些调整，那么，你备份的数据就会和你线上的程序出现不兼容的情况。
有一些公司或是银行有灾备的数据中心，但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候，你就会发现，各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴，宁夏银行7月系统瘫痪最新解析》。
所以，在灾难来临的时候，你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作，但也会导致数据丢失，而且可能长期不用的备份系统很难恢复（比如应用、工具、数据的版本不兼容等问题）。
我之前写过一篇《分布式系统的事务处理》，你还记得下面这张图吗？看看 Data Loss 那一行的，在Backups, Master/Slave 和 Master/Master的架构下，都是会丢的。
所以说，如果你要让你的备份系统随时都可以用，那么你就要让它随时都Live着，而随时都Live着的多结点系统，基本上就是一个分布式的高可用的系统。因为，数据丢失的原因有很多种，比如掉电、磁盘损坏、中病毒等等，而那些流程、规则、人肉检查、权限系统、checklist等等都只是让人不要误操作，都不管用，这个时候，你不得不用更好的技术去设计出一个高可用的系统！别无它法。（重要的事，得再说一篇）
另外，你可以参看我的另一篇《关于高可用系统》，这篇文章中以MySQL为例，数据库的replication也只能达到 两个9。
AWS 的 S3 的的高可用是4个加11个9的持久性（所谓11个9的持久性durability，AWS是这样定义的，如果你存了1万个对象，那么丢一个的时间是1000万年），这意味着，不仅仅只是硬盘坏，机器掉电，整个机房挂了，其保证可以承受有两个设施的数据丢失，数据还是可用的。试想，如果你把数据的可用性通过技术做到了这个份上，那么，你还怕被人误删一个结点上的数据吗？
我的思考：非技术方面
故障反思
一般说来，故障都需要反思，在Amazon，S2以上的故障都需要写COE（Correction of Errors），其中一节就是需要Ask 5 Whys，我发现在GitLab的故障回顾的blog中第一段中也有说要在今天写个Ask 5 Whys。关于Ask 5 Whys，其实并不是亚马逊的玩法，这还是算一个业内常用的玩法，也就是说不断的为自己为为什么，直到找到问题的概本原因，这会逼着所有的当事人去学习和深究很多东西。在Wikipedia上有相关的词条 5 Whys，其中罗列了14条规则：
你需要找到正确的团队来完成这个故障反思。
使用纸或白板而不是电脑。
写下整个问题的过程，确保每个人都能看懂。
区别原因和症状。
特别注意因果关系。
说明Root Cause以及相关的证据。
5个为什么的答案需要是精确的。
寻找问题根源的频，而不是直接跳到结论。
要基础客观的事实、数据和知识。
评估过程而不是人。
千万不要把“人为失误”或是“工作不注意”当成问题的根源。
培养信任和真诚的气氛和文化。
不断的问“为什么”直到问题的根源被找到。这样可以保证同一个坑不会掉进去两次。
当你给出“为什么”的答案时，你应该从用户的角度来回答。
工程师文化
上述的这些观点，其实，我在我的以住的博客中都讲过很多遍了，你可以参看《什么是工程师文化？》以及《开发团队的效率》。其实，说白了就是这么一个事——如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。
这个道理很简单，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些流程、规则、人肉检查、权限系统、checklist等等统统都不管用，这个时候，你觉得应该怎么做呢？是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统！别无它法（重要的事得说三遍）。
事件公开
很多公司基本上都是这样的套路，首先是极力掩盖，如果掩盖不了了就开始撒谎，撒不了谎了，就“文过饰非”、“避重就轻”、“转移视线”。然而，面对危机的最佳方法就是——“多一些真诚，少一些套路”，所谓的“多一些真诚”的最佳实践就是——“透明公开所有的信息”，GitLab此次的这个事给大家树立了非常好的榜样。AWS也会把自己所有的故障和细节都批露出来。
事情本来就做错了，而公开所有的细节，会让大众少很多猜测的空间，有利于抵制流言和黑公关，同时，还会赢得大众的理解和支持。看看GitLab这次还去YouTube上直播整个修复过程，是件很了不起的事，大家可以到他们的blog上看看，对于这样的透明和公开，一片好评。
作者：左耳朵耗子，本名陈皓。Coolshell博主。21CTO社区会员。