面试中一个暴露能力等级的问题

简介: 背景通常我写在文章发表出来之前我问的一些面试题都是我要下架的面试题。就是说我有一个面试题库,我会经常更新,淘汰一些。一般淘汰的问题我才敢拿出来全面分析,避免造成面试时候的不公平。但是有一道题,我面试时必问,我也建议其他的面试官考察这道题。如果面试者能提前准备,回答的很漂亮,再好不过。但是这道题就像自我介绍一样,是个引子。回答的好,会引出下面很多问题。回答的不好,直接决定能力等级的打分。这道题就是:请介绍你遇到的印象最深的一个问题或者故障,请介绍你是怎么发现、处理、分析和解决的。

背景

通常我写在文章发表出来之前我问的一些面试题都是我要下架的面试题。就是说我有一个面试题库,我会经常更新,淘汰一些。一般淘汰的问题我才敢拿出来全面分析,避免造成面试时候的不公平。但是有一道题,我面试时必问,我也建议其他的面试官考察这道题。如果面试者能提前准备,回答的很漂亮,再好不过。但是这道题就像自我介绍一样,是个引子。回答的好,会引出下面很多问题。回答的不好,直接决定能力等级的打分。这道题就是:请介绍你遇到的印象最深的一个问题或者故障,请介绍你是怎么发现、处理、分析和解决的。

回答举例

举例一

描述:一次收到了服务器宕机的告警,从监控上可以看到机器出现故障当时有非常频繁的fullGC。于是进行了重启,发现没有解决问题。所以我们直接开始排查问题原因,从监控中可以看到一个接口请求量高于平时。通过撸代码发现这个接口里有个sql的where条件失效,每次调用都是全表扫描,所以把服务器打挂了。我们用了1个多小时,定位问题后进行了热修复。

连环问1:你们的业务量有多少?在开始排查原因之前,除了重启是否有其他的止血措施?回答:高峰时有几百QPS,出问题正好在低峰期,也就10QPS,所以也没有什么大影响。所以没做其他的止血措施。我算了一下,业务中断1个多小时,影响业务少数也有4W笔。如果不需要承担一些后果,我猜测:要不就是上层领导自己扛下了压力,没有穿透过来,要不就是这个服务不是核心业务。而回答者的止血措施前期准备不足,稳定性意识也不是特别高。属于中规中矩的开发人员。

连环问2:这个问题在测试阶段怎么没发现?

回答:测试用例没有覆盖到。问题的根因是接口的核心逻辑,还不属于边界或者少量场景,我猜测整个团队把关都不是很严,缺少牛人指导。
由于两个连环问的回答技术含量一般,我没有就这个问题继续追问。

举例二

描述:一次与外部进行对接,结果从对接方的服务器上调用接口获取不到数据,我们ping、telnet等命令发现都没有问题,没有办法就进行了抓包,看到数据联通性是好的,就想到可能是配置问题,最终查到配置了包大小的限制导致。我觉得他的回答没有问题,不是我的主要考察方向,我没有追问。从这个回答中,我觉得对他的linux基本命令的掌握达标了。

举例三

描述:做了一个配置中心,用户在使用的时候使用方式不当。公司里主流使用xx1和xx2两种编程语言,这两种语言所用的序列化器肯定是不同的。用户在配置序列化器的使用对整个业务线的所有应用进行了全局配置,把所有服务配置成同一个序列化器。这个地方我们做配置中心的承担少部分责任,主要责任还是用户。本质原因是他们的操作失误,我们还是进行优化,增加了审核环节。连环问1:除了审核,针对配置中心,是否还有其他的优化空间呢?
回答:这个地方我们其实有很完善的文档,用户没有按要求操作我们也很无奈。

这时候,我觉得我们遇到了价值观上的分歧。服务、担当、协同上我们的认知是有差异的,没有谁对谁错,只是有差异。为了避免争执我转移问题到其他不相关问题上。这里说说我自己对此问题的想法:

这里配置中心需要做保证服务健壮性为核心的优化:1>配置需要灰度生效,而不是一次性全局生效。2>针对业务线级别全局配置这种大范围低频配置,应该增加专家审核环节,由配置专家进行把关,确保符合用户预期。3>像涉及到业务线多个服务的配置修改,需要将配置更新下发给涉及的每个服务负责人进行确认,服务负责人确认后才能生效。

配置这件事情,我再多说两句,几个月前刚刚做过调查问题,采样范围不广,也不能说多客观。但是从业界近几年的大事故来看,确实非常值得重视:

后记

前段时间我重温了小时候看的第一部电视剧《雪山飞狐》,小时候看不懂,现在我明白了,整个故事的核心是:一个由于沟通不畅引发的血案。

故事开始,明末清初,李自成有4个忠心耿耿的护卫,分别姓:胡、苗、范、田。起义失败后,他手下3个护卫因事离开,还有剩下胡护卫和李自成。胡护卫为保李自成,忍辱负重,假意投清。实际上在计划一个东山再起的行动,毕竟他们在一个雪山上埋了一个宝藏,还是有资本的。行动都计划好了,就差跟另外3个护卫通气了。这时候去找3个护卫,对于原来的事情没有解释,被3个护卫杀了。临死前说:你们其实打不过我,我让着你们,情愿被杀。但你们千万别让我儿子知道你们把我杀了。不然你们打不过他,会死翘翘的。

我看到这里心里在整理这里面的逻辑:“重要的事情一点也没说,只说了些没用的。不仅如此,最后这段话简直就是在说,我反正死了无所谓,不想辩解。只是我死了,肯定会有人给我报仇,你们也得死。”我突然明白了:这个胡护卫难道是想明白了反清复明不可能成功,但是又不想落个骂名,所以想把这三个反清复明的兄弟杀了,还想找个正大光明的理由,就以自己为饵,让儿子替自己报仇。这样,既可以让天下免受战火之苦,又保全了名声,好心机呀。果然,胡护卫的儿子胡一刀来报仇了,他让三个护卫临死前见了一个人,这个人就是李自成,李自成把当年的事情做了澄清。三护卫觉得自己冤枉了胡护卫就自杀了。临死前什么都没跟家人交代,什么鬼,存心让胡一刀背锅?

胡一刀背着杀死三护卫的锅,田护卫和苗护卫的儿子田归农和苗人凤就来找他了。胡一刀和苗人凤开始了以性命相拼的比武之路。他俩简直是天造地设的CP,惺惺相惜。胡一刀还帮苗人凤报仇,到了苗人凤仇人家,啥都不说,用苗家剑法咔咔咔地把人砍了。连个立地成佛的机会都不给。看其他电视剧,我经常的感觉:都这紧张的节骨眼儿了,你们就先别废话了。看这剧,我的感觉是你们动手前能不能先沟通沟通,着啥急呀?

田归农功夫菜,心眼坏,在苗人凤刀上偷偷喂毒。比武时胡一刀受伤,胡一刀挂了。苗人凤心怀愧疚,见到了自己的人上人蓝,开口闭口就是胡一刀夫妇如何恩爱。两口子结婚第一件事就是带着媳妇见这两个死人。我特明白蓝见到甜言蜜语的田归农,跟着人家跑了,她是看穿了苗人凤是gay。

其实苗人凤深爱自己的前妻,把宝藏地图打成金钗送给了蓝。并且只要蓝活得好好的,就不会杀田归农给胡一刀报仇。蓝很快知道了田归农和自己在一起别有用心,她后悔了。苗人凤也很想让蓝回到自己身边,何况他们还有一个女儿落蓝每天夜里想娘想得偷偷抹泪。然而,他们见面谁也撕不下来脸把心里想的说出来。

蓝过的生不如死,一心求死。死前把金钗交给田归农,让他交还给苗人凤,说:“只要你把这个交给他,他就不会杀你。”苗人凤来了,田归农慌慌张张地把金钗交给苗人凤。苗人凤在剧里终于解释了一回:“田归农呀,这个金钗里就有你心心念念的藏宝图哦。”苗人凤觉得蓝一生都在守护他们之间“钗在人在,钗亡人亡”的承诺;觉得自己在蓝心里比田归农重要。很满意,大笑而去。总结一下苗人凤对蓝做的事情:“他明知道田归农不是好人,完全不和蓝解释,任凭蓝掉进龙潭虎穴。蓝受尽折磨而死,但是死后他知道蓝心中还是他最重要,虚荣心得到满足,没有遗憾了。”这种人为什么能是一个正面人物的设定?

金庸大大用真挚的文笔写出了在那个语言表达匮乏的年代,人们为此付出的代价。

大家都在抱怨现在的面试太卷了。我有切实的感受,我经常面试完叹息一声:这个同学要是在十几年前面试是能过的。可十几年前中国的互联网行业还在抄袭国外,现在经常是被国外抄袭。中国出品的一些中间件也越来越多地被国外使用。

我们所做的只是比十年前更注重方法了,而自己的成长工作和生活中都能用的上。比如这个年代更重视沟通,甚至沟通技能也成为了面试考察的一个重点之一。我们努力训练来的这个技能不仅能更好的促进工作,还能避免《雪山飞狐》里的悲剧,最重要的是让中国在世界上越来越有地位。当然,还是希望少加班,多些时间,休息着、玩着,就把事情想得更明白了。

相关文章
|
5月前
|
弹性计算 Prometheus Cloud Native
可观测性体系问题之ECS管控中重点指标的定义如何解决
可观测性体系问题之ECS管控中重点指标的定义如何解决
33 4
|
4月前
|
安全 Nacos 数据库
【技术安全大揭秘】Nacos暴露公网后被非法访问?!6大安全加固秘籍,手把手教你如何保护数据库免遭恶意篡改,打造坚不可摧的微服务注册与配置中心!从限制公网访问到启用访问控制,全方位解析如何构建安全防护体系,让您从此告别数据安全风险!
【8月更文挑战第15天】Nacos是一款广受好评的微服务注册与配置中心,但其公网暴露可能引发数据库被非法访问甚至篡改的安全隐患。本文剖析此问题并提供解决方案,包括限制公网访问、启用HTTPS、加强数据库安全、配置访问控制及监控等,帮助开发者确保服务安全稳定运行。
450 0
|
数据采集
医院绩效考核源码,强大的指标及考核方案自定义机制
医院绩效考核系统可根据"医、护、技、管理和后勤不同岗位的目标要求,制定和选取相应的考核指标、权重和分值,形成考核办法和计分规则。不同岗位采取不同的考核指标组合,以此构成针对性的绩效评估和激励。
|
Prometheus 监控 Kubernetes
站点可靠性工程 SRE 最佳实践 -- 黄金监控信号
站点可靠性工程 SRE 最佳实践 -- 黄金监控信号
280 0
|
7月前
|
存储 运维 监控
安全防御四部曲---检测实践方案 (多产品结合)
本次方案主要是针对阿里云国际站客户,企业在实际使用阿里云的过程中如何做好运维检测的一些多产品结合的方案介绍。 本篇文章的重点会放在检测(Detection)部分,会具体介绍涉及使用产品配置,FAQ等等,同时对整体的理论框架进行简单的介绍,帮助大家更好理解本部分在运维工作中的分属情况,更好的建立整体性的概念。
427 2
安全防御四部曲---检测实践方案 (多产品结合)
|
存储 监控 数据可视化
有效监控的 10 条基本原则
有效监控的 10 条基本原则
411 0
有效监控的 10 条基本原则
|
数据挖掘
重点人员动态管控预警系统开发方案,情报研判分析平台建设
重点人员动态管控预警系统开发方案运用新一代信息技术和智能化大数据分析,统一构建重点人员管控系统。将辖区内的各类重点人员的基本信息统一采集录入,更新,统一汇总分析研判,分类采取管控措施。
624 0
|
运维 监控 安全
如何用阿里云实行全链路数据追踪
阿里云采用了日志服务,帮助畅捷通构建了用户体验感知、业务安全合规、用户业务链路追踪、成本预算的使用场景,实现了对用户、业务、成本、安全等方面的全维度感知,使得运维效率提升了30%。
752 0
如何用阿里云实行全链路数据追踪
|
监控 前端开发 BI
打造立体化监控体系的最佳实践——分布式调用跟踪和监控实践
本文将从分布式系统调用的复杂现状说起,具体分析调用链的三大使用场景,以及调用链的最佳实践,简述如何将调用链作为排查问题的核心,通过其可以将各类数据关联在一起,提高问题排查能力。
16051 0
|
监控 API 流计算
道旅鬼谷子分享:如何打好业务监控的组合拳
公司由于业务迅速扩展,需要针对业务方面进行定制监控。通过选型最终采用了 ARMS 方案。以下篇幅简单介绍了方案的大致概要以及最终效果,以供读者参考。一套组合拳,在数据分析、实时计算、报警、API、持久化存储等方面给我们节省了不少时间,也提供了更多的可能性。所以,最终我们选择了 ARMS。
2778 0