防伪码：春风酿成蜜桃酒，万物不及你温柔。
一、未来你想成为一个什么样的人？在之后2年，你准备在哪些方面努力？
生活：
1、再优秀一点，碰到喜欢的人就可以名正言顺的心动了
2、就行安安静静做好自己，然后在一些方面偶尔发一点点光
3、有钱人：纯粹一点，幸运一点，俗气一点
4、如果快乐是一种本领，那么我希望你是那个最厉害的人
5、如果你爱着山河，生活一定比谁都清楚
7、努力经营当下，直至未来明朗
8、多认识自己一点，多喜欢自己一点
9、天再高又怎样，踮起脚尖就更接近阳光
10、接受普通，努力出众，诚实的去生活，饿的时候吃饭，爱的时候不撒谎
技术：
1、IT基础设施运维自动化
由于企业要求IT基础设施能够做到高可靠、低延时、大容量、零故障等，那就需要IT运维人员对底层硬件设备进行用心维护，硬件不出故障才能保证上层业务系统的稳定、高效地运行。
2、IT基础设施之上在线业务系统上线
企业在线业务系统是企业对内或对外提供服务的重要途径，IT运维人员在业务系统开发后，能够准确及时上线业务系统是对其业务能力的重要考核标准之一。
3、IT基础设施及在线业务系统监控自动化
对企业IT基础设施及在线业务系统进行有效监控，能够IT运维人员及时获知硬件或业务系统状态，以此判断硬件或业务系统有效服务能力，对硬件或业务系统故障做到即时反馈，即时处理，不影响企业对内或对外提供服务。
4、IT基础设施及在线业务系统日志处理自动化
对企业IT基础设施及IT在线业务系统进行日志处理（收集、分析、监控、趋势图展示等），获知硬件使用或业务系统中用户行为，以此预测下一周期内硬件或业务系统资源可用情况，及时应对用户访问波峰。
5、在线业务系统发布自动化
使用业界先进工具实现在线业务系统代码发布自动化，打破传统IT运维 &34;，实现真正的一键式发布业务系统，加快系统部署速度，实现用户无感知升级或回滚操作等。
6、IT基础设施平台升级
传统的企业IT基础设施平台对企业在线业务系统需要底层硬件平台的高响应、高可靠、大容量等能力反应不及时或不彻底的情况时有发生，这就需要我们IT运维人员能够对传统的企业IT基础设施平台进行升级，把传统的企业IT基础设施平台升级为云平台，由云平台的高响应、高速度、低延时、大容量等能力为业务系统稳定运维保驾护航。
7、在线业务系统迁移至云平台
传统的企业IT基础设施平台升级为云平台后，需要IT运维人员能够把运行在传统的企业IT基础设施平台之上的业务系统迁移至云平台。
8、云平台运行维护（升级）
云平台运行过程中，需要IT运维人才时刻进行监控、对于云平台突发情况进行处理。
9、IT运维自动化系统开发
由于企业IT基础设施运维过程中，涉及多业务、多场景、多平台等，IT运维人员在运维过程中亟需一套本企业的IT运维管理系统，但是由于每家企业的IT基础设施异样性，导致市场上无法采购标准化系统进行应用，大多数情况下由本企业IT运维人员根据企业自身情况进行开发。
10、业务系统海量数据分析及展示
企业在运营过程中产生大量的业务类数据，并且此类数据对于生产、运营等有利于决策，因此IT运维人员需要对企业内部或行业内的数据进行收集、分析、展示等，最终为企业运营提供决策参考依据。
二、如何对开源工具进行二次开发？你的开发思路是什么？
为什么要做二次开发：肯定是因为工具包或第三方框架不满足本公司个性化需求，主要可以采用从简单到复杂可以做：给予框架提供可扩展api进行扩展，对已有代码进行二次封装，修改源代码并替换重新打包发布。
三、Java web服务部署在多台服务器上，一台服务load飙升如何处理？
1、首先定位是由于瞬间请求过多造成的load还是程序本身运行出现问题，通过请求数，请求日志，tcp连接数等对比正常业务量等大致
可以判断。
2、如果是请求过多而其他同类服务都正常，考虑是不是遭受了dos攻击，其次是负载均衡策略是不是有问题，导致几台服务器被分配到的
请求不均匀，再极端一点，可能其他几台服务都出了问题，导致全部请求打到了这台机器
3、如果是程序本身出现了问题，我会去考虑是不是服务器本身某些资源成了瓶颈，导致无法及时处理正常业务量业务，导致程序齐了过多线程或者连接，滚雪球一样滚崩了程序，可能主要是通过日志去排查。
四、测试在服务稳定性上能做什么？怎么落地？
1、功能测试：准备一份经过多方评审的，确保高覆盖度（99.5%）的测试用例，确保系统功能复合需求且无误，此为前提。
2、接口测试：编写经过多方评审的接口测试用例，铺设各种数据场景，用数据驱动接口测试，验证接口的功能和相应的正确性
3、安全测试：前后端检验一致，sql防注入，漏洞扫描等，确保服务安全符合行业标准甚至优于行业标准，保证服务不被行业排斥。
4、性能测试：编写性能测试脚本，或者使用jmeter、lr等工具进行测试，不断加并发数或者数据量，找到性能拐点，进而分析是服务
层、中间件、应用层还是数据库存在问题导致的，然后给出调优方案，促进服务性能优化，此为重点
5、压力测试：模拟线上环境，大数据量且高并发地连续测试数天，测试系统在高负荷下的稳定性，此为重中之重。
五、入职第一天，你需要接手离职同学的代码，并马上开始一个重要需求，你将怎么安排一天的工作？
上午：
1、找领导了解需求
2、对比一下需求在原功能上实现的复杂度和难度
3、找领导确认一下是否一定要基于原框架或者架构实现，如果不用，直接了解一下数据库结构和业务，看看能否用面向切面的方法快速搞定，如果公司比较注重代码的风格一致性和可维护性，需要进一步了解代码现状。
中午：
请离职的兄弟吃个饭送送温暖，增进一下感情，顺便互换手机号，防止后续项目有问题跟不上。
下午：
1、找离职的同学要软件开发的代码库、架构文档、数据库结构文档
2、和离职兄弟一起过一遍代码，主要涉及代码增删改查的方法类、权限控制、打包发布方式、版本管理方法、协同作业规范、多业务交叉说明，并做好记录
3、对下个需求工作量做简单评估，并做出汇报。
六、说明情况下需要进行jvm调优？你觉得最好的调优策略是什么？
1、就考虑jvm需要的内存总大小，比如tomcat的内存给分多了用不了，分少了内存不够，导致频繁的GC，内存溢出
2、各块内存的分配（新生代、老年代、存活区）
3、选择合适的垃圾回收算法，控制GC停顿次数和时间
4、解决内存泄露的问题
5、检查哪些对象在系统中数量最大
6、死锁检查
7、dump线程的详细信息
8、检查哪些方法占用了大量cpu时间
七、用户在浏览器输入一个地址到页面渲染完成，经历了哪些过程？
1、浏览器会开启一个线程处理请求，对RUL分析判断如果是http协议就按照Web方式来处理
2、调用浏览器内核中的对应方法，比如WebView中的loadurl方法
3、通过DNS解析获取网址的IP地址，设置UA等信息发出第二个GET请求
4、进行HTTP协议会话，客户端发送请求报头
5、进入到web服务器上的Web Server，如Apache，tomcat，node.js等服务器
6、进入部署好的后端应用，如php、java、JavaScript、python等，找到对应的请求处理。
7、处理结束回馈报头，此处如果浏览器访问过，缓存上有对应的资源，会与服务器最后修改时间对比，一直则返回302
8、浏览器开始下载html文档（相应报头、状态码200），同时使用缓存
9、文档树建立，根据标记请求所需指定MIME类型的文件（比如css、js），同时使用缓存
10、页面开始渲染DOM，JS根据DOM API操作DOM，执行事件绑定等，页面显示完成。
八、你会通过什么样的方式快速锁定目标公司的决策人
带几个性格不同体能不同的男女和这个人一起爬山。半天内大家都能开心到达山顶，这人就是高手
九、如果核心线程数、最大线程数、等待队列长度都是10，此时来了15个任务，会出什么问题？
5个线程进入等待队列
十、在web页面中，如何检测用户从点击到页面响应的延迟时间？
后端在页面生成时植入JS代码记录服务端时间戳，前端也计算download到ready到rendered时间，再考虑本机与服务器的时间差，就可以计算出并ajax提交用户从点击链接打开页面直到元素渲染出来的所有时间段的耗时。这个可以用图表查询。
十一、线程池中的线程的生命周期是怎样的？如何安全的关闭？
周期的六种状态：新建——可运行——被阻塞——等待——计时等待——被终止
十二、在产品快速迭代和试错的过程中，研发应该如何保证和提升工作效率，有什么好办法？
1、使用符合业务开发的敏捷的开发模式，规范开发和部署流程
2、按照以上流程一切能自动化都尽可能自动化，一切能协同化尽可能协同化。包括产品设计共享、UI设计共享、代码、测试、部署、尽可能实现CI/CD，贯彻devops、实践最佳的投入和产出平衡点
3、基础设施“资源化”，直接调配而不是搭建，能用成熟技术就用成熟技术
4、一个符合业务发展轨迹的有预见性的架构规划。最大化架构思考，最小化架构实现
5、贴近业务、理解业务、关注用户的体验、在质量效率成本方向找一个均衡，以技术导向为优先
6、形成知识库，把一些公共的问题或者重要的问题记录，比如wiki、confluence，可以供人员查找，以便快速解决问题
7、定期复盘。针对每个迭代的内容，可以做以下原因分析及缺陷分析，查找如何解决问题及原因。以便后续可以规避这些问题
十三、如果让你自己实现分布式锁，你会重点关注哪些方面？为什么？
常见的分布式锁：
1、基于数据库实现分布式锁
2、基于缓存（redis）实现分部锁
3、基于zookeeper实现分布锁
锁的占用时间限制：redis就有占用时间限制，而zookeeper则没有，最主要原因是redis目前没有办法知道已经获取锁的客户端状态，是已经挂了呢还是正在执行耗时较长的业务逻辑。而zookeeper通过临时节点就能清晰的知道。如果临时节点不存在说明已经执行完毕释放锁或者挂了。由此看来redis如果能像zookeeper一样添加一些与客户端绑定的临时键，也是一件好事。
是否单点故障：redis本身有很多种玩法，如客户端一致性hash，服务端sentinel方案或者cluster方案，很难做到一种分布式锁方式能应对所有这些方案。而zookeeper只有一种玩法，多台机器的节点数据是一致的，没有redis的那么多麻烦因素考虑
总体来说，zookeeper实现分布式锁更简单，可靠性更高。但是锁这个问题还是后期测试的方案比较重要
十四、如何解决在商品库存秒杀场景下，单行数据频繁更新带来的行热点问题？
1、前端层面
a、前端是整个流量的入口，正常业务访问时系统表现平稳，但是当有人恶意请求时，需要加上流控措施，比如常见的
需要用户回答问题，填写验证码，移动图形等，防止或者减少有机器人来恶意请求。
b、页面上采用机防止机器人的判断 两秒以内的请求一律拒绝
c、通过设置nginx，对同一个ip源的请求次数做限制，防止机器人来申请
2、应用层
应用层序接收前端请求，进行一系列的数据库操作，在我们规避了恶意请求之后如果还是有大量的数据写访问请求，我们需要
a、对业务做降级，选择不更新请求次数，弱化该商品申请次数的展现
b、通过异步更新来避免直接写数据库
应用使用分布式缓存(比如tair)来存储某项商品的申请次数或者某人的申请次数，以商品id/user_id为key，申请试用人数为value,有用户申请成功则更新申请试用人数。不需要查询和实时写数据库，每隔一定时间/次数将结果写入数据库。
3、数据库层
前面介绍
a、将热点数据拆分，分在不同的库不同的表中，分散热点数据，减轻数据库并发更新热点带来的RT升高和应用连接等待时能保证业务能够正常访问其他商品表,损失局部可用性。
优点:实时读写数据库，前端展示数据的准确性。缺点:业务逻辑稍显复杂。
b、限流补丁
针对某些特定的sql语句从MySQL层面加以限制,当系统thread_ _running 达到一定值或者某个sql执行时间超过一-定阈值则拒绝该sql的执行。(阿里内部已经实现限流版本)
c、使用MySQL的thread pool功能,在并发较大时，会引起Innodb的mutex锁争用。当前解决方法是通过innodb_ _thread_ concurrency 参数，但是该参数自身也存在锁争用，同样影响了MySQL的性能。在我们的优化历程中，也尝试通过优化该参数,来解决并发情况下,性能降低的问题。
优点: Thread pool主要从四个方面考虑:减少SQL并发,使得有足够的资源:使用线程组独立管理:使用优先级队列,限制并发执行的事务:避免死锁。
缺点:在测试过程中发现，会有大量的连接等待
kernel mutex锁,但是持续的压力会导致MySQL的thread running,最终导致mysql不可用。
十五、使用关系型数据库如mysql和文档型数据库如MongoDB时，数据模型设计有哪些区别？
mysql为表结构，而且操作时必须严格按照表结构执行，适合存储和用于关系非常强的数据项目上，比如说班级对应的学生个数，学生姓名，性别等
MongoDB表型形式为文本流，数据表之间基本上没啥联系。他这个形式就是你用word文本文档有序或者有类名的事物和事项，而且你想怎么加新都可以（mysql不可以），而如果加的事项已存在，他就会合并
十六、什么是缓存穿透？怎么解决？
缓存穿透又称缓存击穿，是指在高并发场景下缓存中(包括本地缓存和redis缓存)的某一个key被高并发的访问并没有命中，此时会去db中访问数据，导致数据库并发的执行大量查询操作，对db造成巨大，压力。
1.对缓存失效的key加分布式锁，当-个key在本地缓存以及redis缓存中未查询到数据，此时对key加分布式锁访问db，如果取到数据反写到缓存中，避免大量请求进入db;如果取不到数据则缓存一个空对象，这样可以保证db不会被大量请求直接打挂，从而引起缓存颠簸，更甚者缓存雪崩效应。
2.在本地缓存一个set集合，存储对应数据为空的key的集合，在请求前做拦截，此种方式牵涉到数据变更还要校验set集合的问题，一般适用 于数据更新较少的场景
3.使用布隆过滤器
十七、https和http的区别是什么？
传输信息安全性不同
1、http协议:超文本传输协议，信息明文传输。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息
2、https协议:具有安全性的ssI加密传输协议，为浏览器和服务器之间的通信加密，确保数据传输的安全。
连接方式不同
1、http协议: http的连接很简单，是无状态的。2、https协议:是由SSL + HTTP协议构建的可进行加密传输、身份认证的网络协议。
端口不同
1、http协议:使用的端口是80。
2、https协议:使用的端口是443.
四、证书申请方式不同
1、http协议: 免费申请。
2、https协议:需要到ca申请证书，-般免费证书很少，需要交费。
十八、Cookie的工作原理是什么？
HTTP协议是无状态的，无法记住客户端身份，cookie被设计用来解决无状态的问题，服务端在上一次请求往客户端写入cookie，下一次请求客户端带上cookie，服务端解析内容便可知道客户端身份
十九、一个好的技术总监应该做到哪些事？
技术团队的规模不同，技术总监的要求也不同，以50人左右，包含大数据team, java服 务器team，运维team，前端team和测试team的技术团队为例， 说说自己的体会:
1、技术能力，技术总监的核心竞争力还是自己的技术能力。技术能力要广，也要尽可能的精，要精通大数据和java服务器段的技术，因为这两块的开发工作量最大，涉及的人员也最多。只有精通相关技术，才能做出各类(例如进度的把控，架构方案的拍板)正确决定。对于运维，前端和测试的工作，也要能够做到，了解他们使用什么样的技术，这个技术能给工作效率带来哪些提升。
2、基于技术的判断力，能够独立的准确判断尽可能多,同事的技术能力(如果 你有比较强的review代码的能力，这件事就不是很难)。 这样既有利于把关键的任务分配给正确的人，也有利于团队的同事把自己的精力更多的放在提高自己的技术能力，上。
3、持续学习的能力，这是个技术持续更新的时代,新的技术在不停的出现，你的下属同事也在不停的进步，这就要求你自己也要不断的学习新的技术，并尽可能把新的技术引入到实际应用中。
4、保持团队的良好风气，实现正向循环，要建立良好的评价，奖励机制和选拔机制，杜绝劣币驱逐良币,给专心工作的技术人员一个良好的工作环境。这就要求技术总监不断提高个人的业务能力，个人修养，职业素养。
5、让领导保持信任你，你带着这么多技术员，可以算是“手握重兵”，你的领导一定会格外关注你，这个时候，该这么做，我的总结是：做好本职工作，低调谦和，公平公正，不拉帮结派，心态开放，服从直属领导（不盲从有原则），不瞎掺和。当然每个领导的性格，格局和最终利益都不一样。所以最根本的工作还是做好本职工作
6、做一个长期主义者
二十、如果请你给运维新人几个忠告，你会说什么？
1、不懂就问、想好再问、问完确认、确认上报、工作留痕。
2、多搞linux，别走网工方向，国内网工只能走安全但是不走路由交换，安全走不通、所以多搞搞、自动化、python、k8s，Prometheus等
3、学会甩锅，做好异地备份，不要使用root操作，危险的操作一定收到邮件才干活
4、缺钱了可以干半年外包，不能干时间太长。
5、多看书，多关注行业动态，尽量去大厂。
