工程师文化

DevOps面试问题 01 您能告诉我们DevOps和Agile(敏捷)之间的根本区别吗？ 答：尽管DevOps与敏捷方法（这是最流行的SDLC[Software Development Life Cycle]方法之一）有一些相似之处，但两者在软件开发方面都是根本不同的方法。以下是两者之间的各种基本差异： 敏捷方法 敏捷方法适用于敏捷中的开发同时敏捷方法适用于DevOps中的开发和操作。 实践和流程 敏捷涉及敏捷Scrum和敏捷看板等实践，而DevOps涉及CD（持续交付），CI（持续集成）和CT（持续测试）等流程。 优先级 敏捷优先考虑及时性，而DevOps优先考虑及时性和质量。 发布周期 DevOps提供较小的发布周期并提供即时反馈，而敏捷仅提供较小的发布周期而没有立即反馈。 反馈源 敏捷依赖于客户的反馈，而DevOps涉及到自身（监控工具）的反馈。 工作范围 对于敏捷，工作范围仅是敏捷，而对于DevOps，这是敏捷和对自动化的需求。 02 为什么我们需要DevOps？ 答：如今，很多组织或企业正试图通过一系列的发布小的特性传递给客户，而不是发布大的特性集。这样做有几个好处，包括更好的软件质量和快速的客户反馈，所有这些好处导致更高的客户满意度，这是任何产品开发项目的最重要目标。为此，公司需要： 增加部署频率 缩短修复时间 降低新版本的失败率 万一新版本崩溃

年末将至，大批攻城狮与程序猿早已蠢蠢欲动，开始了跳槽涨薪之旅，虽然受社会大形势影响，IT行业虽然无法和前几年的突飞猛进的势头相比，但是对DevOps的热度却只增不减，工程效能团队的普及率正在迅速增长，对DevOps工程师需求量也是呈指数式增加。转型做DevOps工程师、DevOps教练也是逐渐成为IT圈的时尚。那么如何在大量的DevOps工程师中脱颖而出，打破开发与运维之间的隔阂，成为团队内首屈一指的DevOps专家呢？ 首先，DevOps没有初级工程师的说法，只要你了解这个领域，就会知道，需求、开发、构建、测试、安全、发布、部署等都是DevOps工程师必备的能力，为此我们查看所有招聘软件，DevOps工程师的招聘JD中，都会要求候选人了解git、jenkins、sonarqube、ansible、zabbix、docker、k8s、saltstack、java、python、shell、nginx、F5、mysql、redis等等等。如果这些工具、语言全部都了解，怕是初级工程师很难做到。所以一旦进入了这个领域，已经成为一位高级工程师，并且有足够的能力能Hold上述开源工具及语言了。这些都是DevOps工程师应该具备的硬实力，如果感觉自己在DevOps这个领域没有进步空间，请打开招聘软件随便看一个岗位需求，自然就会知道自己欠缺的技能。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 信必优全球的交付网络，可以建立独一无二的产品研发流程和沟通渠道，我们为此感到自豪。这给了我们与开发人员、IT专业人员、测试人员、工程师沟通合作的能力；简单来说，我们相信和客户像团队一样工作，可以合作实现软件交付和基础设施建设流程自动化。作为一个全球化的供应商，我们致力于开启一种文化氛围，在这里创建、测试和发布软件迅速可靠，质量最佳。 我们的服务能力 首先我们从您的需求文档开始，您想做些什么—您目前的客户有哪些和您能提供哪些服务。如果您只是刚开始并且目标还不清晰-没问题-我们可以与您一起制定行动计划。当您的产品准备发布了，我们也可以继续为您提供后续支持服务。我们定制的沟通策略和工具组合完全可以满足您现有客户和潜在客户的需要。然后，我们将产品推向市场，进行测试，并处理由此带来的各种请求、反馈。 DEVOPS SERVICES 开发和运维服务 24X7小时平台和应用监控 专业故障解决和升级管理能力 系统和平台的安装和维护能力 操作系统和应用程序支持一级响应 跨国企业离岸开发 高水平系统平台工程师，支持所有主流系统平台 (Unix, Linux, Windows) /DBA (Oracle, MySQL, etc.) 监控解决方案: HP Open View, Remedy, Altiris, Opsview,

软件架构最佳实践、企业架构模式以及系统描述的正式方法都是非常重要且实用的工具，总会有合适的场景让它们发挥作用。但在设计系统时，请从简单始、以简单终，尽可能避免一切会无谓提高复杂度的架构与正式工具。 我的职责是设计和构建大型系统。我参与重写了 Uber 的分布式支付系统，设计并交付了 Skype on Xbox One，开源了 Uber 的移动架构框架 RIBs 。所有这些系统都进行了彻底的设计，经过多次迭代和大量讨论。然后，这些设计被记录到设计文档中，在我们开始构建之前分发出去，从而获得更多的反馈。 所有这些系统的规模都很大：有数百名开发人员在构建它们——或者以它们为基础进行构建——并且它们支撑着每天数百万人使用的系统。它们不仅仅是绿地项目。重写的支付系统就是用于替换两个已有的支付系统，有几十个系统、数十个团队在使用它们，但所有这些都没有对业务产生任何影响。重写 Uber App 是一个由数百名工程师同时参与的项目，他们将现有的功能移植到一个新的架构中。 让我先说些可能会让你觉得吃惊的事。 首先，这些设计都没有使用任何标准的软件架构规划工具。 我们没有使用 UML ，没有使用 4+1 模型，没有使用 ADR ，也没有使用 C4 和依赖关系图。我们创建了大量的图表，但是没有遵循任何严格的规则。只是使用了普通的方框和箭头，类似于这个描述信息流的图或这个概括类结构和组件之间关系的图

好的工程师，无法忍受低效且无趣的工作。优秀的技术团队应该自上而下的地推进技术平台化建设、DevOps、自动化构建、测试和部署流程，积极采用合适的第三方工具或创造工具，进行周期性的前沿技术分享等等。 先来看看国内外公司关于工程师文化的分享~ What makes a good engineering culture? 建立一个良好的工程文化无疑是一个大量的工作，但由此产生的工作环境是值得的。 @edmondlau@Twitter 的这篇文章讲了如何打造一个有工程师氛围的团队，需要知道的 10 件事情。英文原文： 链接 ；中文翻译： 链接 .(PS：中文翻译来自微信公众号*@董老师在硅谷*) 前豆瓣首席架构师：如何保持团队的技术氛围？ “在技术团队建立起技术导向的价值观、良好的工程师文化，才能保持一个技术团队的创新与活力。” 洪强宁 （前豆瓣首席架构师）的这篇文章，从技术导向、分享精神、鼓励创新、工具文化等方面进行了分享。文章 传送门 。 什么是好的工程师文化？欢迎分享你的想法到微博 @风起云飞firim 或者 dm[at]fir.im. 再来看看本期 fir.im Weekly 的技术干货分享～ 『iOS，Android 开发干货分享』 从 0 到 1 搭建移动 App 功能自动化测试实践 @debugtalk 基于当前项目的开发模式，对整个 M

本文已经首发于 InfoQ中文站 ，版权所有，原文为《XXX》，如需转载，请务必附带本声明，谢谢。 InfoQ中文站 是一个面向中高端技术人员的在线独立社区，为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如 QCon 、线下技术交流活动 QClub 、免费迷你书下载如 《架构师》 等。​ 在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。 确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量