1 项目发布流程？
2 项目管理怎么做的？用什么工具？
3 为什么需要 DevOps ？DevOps有哪些优势？
技术优势：
- 持续的软件交付
- 缩短修复缺陷的交付时间
- 更快地解决问题
商业利益：
- 更快速地传递功能
- 更稳定的操作环境
- 有更多时间可以增加价值（而不是修复/维护）
4 DevOps跟传统开发的区别？
- 手动 ——》自动
- 线性 ——》闭环
5 Devops是什么？DevOps怎么落地？
DevOps定义
DevOps是Development和Operations的组合，是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合，以期打破传统开发和运营之间的壁垒和鸿沟。
DevOps并不指代某一特定的软件工具或软件工具组合。各种工具软件或软件组合可以实现DevOps的概念方法。其本质是一整套的方法论，而不是指某种或某些工具集合，与软件开发中设计到的OOP、AOP、IOC（或DI）等类似，是一种理论或过程或方法的抽象或代称。
DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。具体来说，就是在软件交付和部署过程中提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。
DevOps落地
- 工具
- 流程
- 文化
6 CI(代表产品Jenkins)
CI (Continuous Integration)，持续集成。开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。 主要用于整合团队开发中不同开发者提交到开发仓库中的项目代码变化，并即时整合编译，检查整合编译错误的服务。它需要一天中多次整合编译代码的能力，若出现整合错误，可以优异地准确定位提交错误源。
7 CD
- CD，Continuous Delivery，持续交付，并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。
- 持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段。
- CD，Continuous Deployment，持续部署，意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。
8 AB Test与灰度发布？
AB测试就是指把少部分用户分成平均的两组，其中一组用户体验网站改版的A版本，另外一组用户体验网站改版的B版本，分别记录清楚相关的所有用户操作数据以后再进行精确的比对，最后分析得出哪一个版本是用户最喜爱的。
灰度发布则是指在新的功能上线以及没有上线之间能够保证新的版本可以稳定过渡的一种发布方法，可以在灰度发布的过程当中解决一些问题或者对新版本做出一些可以提高用户体验的调整，这是保证网站可以平稳更新到新版本的有效过程。
那么AB测试和灰度发布关系就非常好理解了，可以说AB测试就是灰度发布的一种表现方法，当然除了AB测试以外，灰度发布还有其他的发布方法，但是最经常用到的，也最有效果的就是AB测试法了。
AB测试方法可以通过大量的用户真实数据来得出用户的具体操作行为喜好，网站可以根据用户的操作行为来对新版本进行必要的改进工作，除了用户的体验以外，设计方面的考虑以及系统的质量方面都是要考虑到的，要保证网站可以顺利的过渡到全新的版本，网站改版的最终目地还是增加用户的粘性以及付费率，所以出发点一定要明确，在保证网站没有技术性漏洞的前提下，要最大程度的从用户操作习惯的角度出发来进行必要的改版工作。
以上就是我们为大家总结的AB测试和灰度发布关系了，可以说这两者是一个包含的关系，灰度发布方法里面是可以包含AB测试的，反之，AB测试是灰度发布众多方法当中的其中一个。
9 TDD、BDD、ATDD、DDD
- TDD：测试驱动开发（Test-Driven Development）
测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论，TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。大行其道的一些模式对TDD的支持都非常不错，比如MVC和MVP等。
- BDD：行为驱动开发（Behavior Driven Development）
也就是行为驱动开发。这里的B并非指的是Business，实际上BDD可以看作是对TDD的一种补充，让开发、测试、BA以及客户都能在这个基础上达成一致，JBehave之类的BDD框架。
- ATDD：验收测试驱动开发（Acceptance Test Driven Development）
通过单元测试用例来驱动功能代码的实现，团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员，强调如何实现系统以及如何检验。
- DDD：领域驱动开发（Domain Drive Design）
DDD指的是Domain Drive Design，也就是领域驱动开发,DDD实际上也是建立在这个基础之上，因为它关注的是Service层的设计，着重于业务的实现,将分析和设计结合起来，不再使他们处于分裂的状态，这对于我们正确完整的实现客户的需求，以及建立一个具有业务伸缩性的模型。
10 黑盒测试、白盒测试、灰盒测试
- 黑盒测试：外科
- 灰盒测试：介于外科和内科之间
- 白盒测试：内科
11 全链路压测怎么做？
1、核心链路梳理
各业务研发团队的owner对我们目前的核心业务链路进行了梳理，主要包括：首页、商品、订单、支付、用户、风控、优惠券、大促活动、基础服务。下面为示意图表：
2、镜像环境准备
由于本次压测是在和生产等配的镜像环境进行，相当于从零开始搭建一套环境，无论是资源准备、服务部署还是服务联调验证，都耗费了较多的时间，从中也发现了我们之前的一些不足，累积了很多经验。
3、压测任务排期
根据大促任务规划，性能测试同学从中拆解出了较为详细的压测任务，并进行排期，同时积极主动的推动了整个压测任务的开展实施。
4、专项预案沟通
专项预案主要包括如下几项：限流、降级、熔断、脉冲、破坏性验证五种场景。
5、大促指标沟通
为保证压测流量和生产预估流量对齐，由技术负责人牵头，和运营产品同学进行了多次沟通，确认了本次双十一大促活动相关的活动场次、时间段、优惠券投放量、预估DAU等相关关键指标。
6、压测模型梳理
压测模型的梳理，主要包括核心业务链路的优先级、调用依赖关系、流量模型转化（漏斗模型）等，限于保密措施，这里不过多介绍。
7、流量模型梳理
关于流量模型，建议梳理出核心交易链路对应的依赖大图，并粗估双十一峰值数据，作为接下来压测、性能优化的技术目标。
8、线上容量评估
为了在压测开展前对目前线上的服务容量有一个初步的了解，需要对各个核心服务、消息队列、缓存以及DB的容量进行了梳理汇总。
9、线上链路监控
监控就是我们的眼睛，有了监控，才能快速发现问题并定位修复问题。这一点，基础架构的同学为此做了很多工作。比如：链路追踪监控的Cat、可视化监控大盘Grafana以及更多的监控组件。
10、压测数据准备
为了尽可能保证压测数据的真实性，我们的解决方案是复制生产库的数据，进行脱敏和可用性验证，用来做压测的基础数据。在数据脱敏和可用性验证这点需要高度重视。
11、资损防控梳理
由于现在双十一大促活动主要玩法都是优惠券以及满减相关，且涉及到订单支付业务，因此资损防控也是准备阶段的重中之重。
12、确定性能水位
为了精确测定各服务单机的水位性能，并留存一定的buffer作为流量高峰时刻的缓冲，结合业内经验和我们当前的系统情况，最终确定以单机40%的水位性能作为线上扩容和容量规划的验收标准。
13、输出测试方案
前期做了相当多的准备工作，在正式开展全链路压测之前，性能测试同学输出了本次双十一全链路压测的测试方案，通过评审后，全链路压测工作就可以正式开展。
12 性能测试怎么做？
12.1 性能测试指标
- 响应时间
- 最大并发用户数
- 吞吐量：单位时间内系统处理用户的请求的数量
- QPS：Query per second，每秒系统能够处理的查询业务数量
- TPS：Transaction per second，每秒系统能够处理的事务数量
制造行业：10TPS~50TPS
金融行业：1000TPS~9000TPS
保险行业：100TPS~1000TPS
互联网电子商务：10000TPS~100000TPS
互联网中型网站：100TPS~500TPS
互联网小型网站: 50TPS~100TPS - HPS：HTTP per second，每秒系统处理的HTTP请求数量
- 性能计数器：描述服务器或操作系统性能的一些数据指标。
- 使用内存数
- 进程时间
- 资源利用率
根据《摩诃僧祗律》记载 ：一刹那者为一念，二十念为一瞬，二十瞬为一弹指，二十弹指为一罗预，二十罗预为一须臾，一日一夜有三十须臾。
结论：一瞬间为0.36 秒,一刹那有 0.018 秒.一弹指长达 7.2 秒
12.2 性能测试工具
- ApacheBench：轻量级工具，主要用于HTTP协议的性能测试，没有图形界面
- Apache JMeter：开源
- HP LoadRunner：闭源，最初是Mercury公司开发的，后被HP收购
13 自动化测试
Selenium
14 mock&打桩
- 打桩，为被测服务的请求创建一些有着预设响应的打桩服务。比如设置积分账户，当有请求查询客户aaa的余额时，它应该返回100万，这时候的测试不关心这个打桩服务被访问了多少次。
- mock，在打桩基础上还会进一步验证请求本身是否被正确调用。如果与期望请求不匹配，测试便会失败。
15 蓝绿部署&金丝雀发布区别？
- 蓝绿部署，部署两份，但只有一份接受真正的请求，另一份经过冒烟测试后，切换流量到新版本。
- 金丝雀发布，灰度发布，将部分生产流量引流到新部署的系统，来验证系统是否按照预期执行，新旧版本共存的时间更长，而且经常会调整流量。
16 摩尔定律&康威定律
- 摩尔定律：集成电路集体管的数目每18个月翻一番。
- 康威定律：如果你有四个小组开发一个编译器，那你会得到一个四步编译器。康威定律强调的是系统架构跟组织结构相匹配。
