“工程轮岗”文化，最开始在2010年的时候，工程轮岗项目是每年的一些特定的时刻，可能运维就会很累，这个时候运维的人手就不足，公司就开展了这样一个活动，大家都去学习怎么做运维，在运维很忙的时候，大家能去搭把手帮帮忙。后来公司发现这样一个活动不仅仅在运维层面，我们还可以在所有的工程师的岗位上做这样的事情。我们通过这个活动能够让全公司，让大家更好的产生同理心，更好的去理解别人的工作。整体提高大家的协作互助的意识。

最后关于质量文化，这个公司像陆老师说的一样，单元测试，代码的测试覆盖率是很重要的，当我们看到代码覆盖率的时候大家就想到了一点，比如做了很多的单元测试，我的覆盖率很好，但是如果一个工程不做单元测试会产生什么样的情况呢？并不是说仅仅的缺乏单元测试而已，如果不做单元测试就会发现有些代码，甚至有些函数几十行甚至几百行的函数都有，其实这样的工程它的可测试性是非常差的，我们通过单元测试去让大家把可测性做的更好。

济南网站建设公司就是多样性和包容性的，多样性是因为公司运营着一个社区，这个社区什么样的人都有、什么样的情况都会发生，所以，在技术岗、研发岗以及管理层面可能也都会有不同的情况，比如有不同的性别、不同的肤色、来自于不同地域的人，通过公司的包容性、多样性的队伍，创造一个更友好的环境，鼓励大家的创新和协作，以及一些想法上的交流。公司的6个管理层只有2个是男性。

我们现在进入第三章，关于公司简单介绍一下。左图是Etsy的创始人罗伯·卡林，右侧的是查德迪克森也是灵魂人物。公司的创业宣言：“为爱手工制品的人们提供交易和交流场所”。如图，这是公司几位CEO。最核心的灵魂人物，查德迪克森，2008年的时候他以CTO的身份加入公司，到2011年他成为了这个公司的CEO。在他在的这段时间，公司也起到了很大的变化，主要是工程上面，2017年西尔弗曼上台。罗伯阶段公司诞生了，到查德迪克森阶段提高了它的能力，到他壮年的时候空有一身本领但是不知道本领怎么变现，这时候西尔弗曼来了，自从他上台之后整个公司股价一直在向上爬升，一直到现在。

最后再跟大家说一下公司工程文化的演进，公司主要有4大项：1、放权和信任；2、集体责任；3、持续的学习；4、相互督促结伴而行。

它的工程演进史，公司在2005年6月18日成立，发展到2008年的时候，公司从4个人慢慢成长到了三、五十人，这时候也是出现了沟通不畅、每个部门各自为政这样的情况，到了2008年的时候，公司觉得这样不行了，管理层做了调整，由玛丽亚·托马斯和查德迪克森两位高管，一个负责运营，一个负责工程，工程文化的演进从那时候一直到现在，开始了他们的DevOps之旅，从每日的站会，把沟通问题先解决掉，然后建立一种好的协作机制。演进之路分了5个部分，比如，那个时候网站稳定性不够好，所以做了一些改进，引入了持续部署，当时公司的一些不好的技术也都废弃掉了，包括数据库层面的改造。

关于公司的工具文化，简言之，工具是我们很多文化、很多价值的体现，工具只是一部分，只是一个窗口，通过这些工具的建设可以把一些不确定的事情确定下来，大家不断的持续的优化、迭代工具的情况。

其实刚刚我们第一点说了，质量保障之道归根结底为什么能够做到这么好？这才是核心，就是公司的持续集成、持续发布以及持续部署，其实就是一个阶段一个阶段来的，也就是解决了我们产品快速的创新，最重要的是解决掉平均的恢复时间，因为大家关注工程能力的话，MTTR是非常重要的一个指标。

大家也能看到这张图，是一个持续的流水线，从最开始的开发、集成到最后测试阶段，到最后的上线，也就是说每一个阶段往下游走时，哪一环节有问题都不会顺利的走到下一个环节。

也就是在告诉我们这样的情况是很好的，我们最后看到的东西都是测试通过的，都是质量达标的，当我们很多条流水线，很多条任务都是这样做，都是没有问题的，为什么最后生产的时候还是出了问题呢？是说我没有做单元测试吗？还是说我的覆盖率不够？也许是数据的问题，也许是配置的问题，是测试环节或者集成环境跟生产环境的容量与负载的不匹配导致的吗？如何解决这样的问题，我们努力的去测试，努力的去提高，就能避免这样的问题吗？显然是避免不了的。既然避免不了，如何保证我们的质量呢？首先提及两个概念，也就是刚刚提到的MTTR还有一个是MTTD。

在我们上线之后，还是要做很多的监控工作，像每个公司都有一些预警/报警，也就是说最后绿色的这一部分，上线之后绿色部分要做到的是什么，就是在提升我们的MTTD，也就是说，当问题产生的时候我第一时间就要被通知到，这样我才能在第一时间去采取对应的措施。

假如我们一个月要部署的代码行数是5万行的话，如果按照之前的模式，不引入持续部署的机制，有可能是开发了一整月，到最后的时候5万行代码一起上线，好的情况就是什么问题都没有，不好的情况就是出现了问题，那么一旦出现问题我们一次性Deliver了5万行代码，修复时间会很长。如果用流水线的方式做的话，拆很多很多个流水线去发布，这个时候我们感知到错误的可能性是非常高的，而且我们每次的发布可能就几十行，至少不超过一百行的代码，这样发生了问题，很快的就知道问题所在，很快的就可以解决了它，很快的再去迭代发布，这个问题就没了。也就是说我们MTTR的问题。这个公司每次发布部署的东西很多，部署的频度很低，一周部署两次左右，现在一天要部署几十次或者更高，可能对于大家而言互联网行业一天部署50次简直太少了，但是对于这个公司而言它这几年的变化还是很快的，而且按照这个公司目前的工程文化的发展持续学习，即便将来公司做的很大了，不像现在八九百人的规模，更大了，我相信也依然会做的很好的。

公司整个架构演进就是从2007到2011年的架构演进，也就是到现在这个公司主要的开发语言还是用的PHP，整个公司的技术演进时间轴如图，在不同的阶段引入了不同的技术，随着人员的规模变化，也逐渐沉淀出了相应的工程师文化，无论是技术还是文化都是在慢慢的演进出来的。

最后“运营模式”，会后大家再看吧，因为今天时间不多了，我简单给大家说一下。最简单的介绍一下Etsy这个公司是做什么的，它是一个在线电商，这是一个标签，它的品类比较有限，我们这个平台只卖手工制品，不支持批量，而且在这个平台上要想开店，首先你得是一个手工艺人，公司会去审核，一旦他发现你作为一个手工艺人在这儿开了个店，卖着从中国义乌来的产品，可能这个店就要被封掉了，它是不允许批量买卖的，可能涉及的方面也很多，而且这个网站的卖家和买家，70%以上都是女性用户，可能女生更在意唯一性之类的事情。近期的一些热点，针对这个公司的新闻也蛮多的，公司做的很多事情有可能不一定是在完全维护买家或者卖家某一方的利益，很多的规则可能还是来自于整个社区的反馈。

针对这个公司收益率、市盈率的情况，我也问了一下，包括美股的资料，这个公司的市盈率数字看起来还是有泡沫存在的。

转载自：Testin云测