数美时代架构岗校招面经（已拿offer）

一面
一面没什么好说的，在面试前半个小时会给你三道题，很好做，基本都是牛客中等难度。
正是面试自我介绍等等，题目记不清了，基本就是数据库，Go的基础，还有一些架构方向的知识，比如分布式什么的，基本上基础知识扎实就能过
二面
二面开始上强度了，HR人很好，和我说二面会有场景题，上来就场景题，难度非常大，而且很开放
1.问：假如某某模块的api访问耗时突然上涨，你应该如何排查
答：从系统架构出发，排查调用路径上可能存在的每个服务节点的耗时情况，定位到关键节点后通过time计时器查看高耗时位置代码，再逐一排查问题情况
面：可以但不对，应当要保证客户的api调用时长不能再恶化，你应该避免使用可能会增加调用耗时的方式
deepseek:
立即验证问题并检查现有监控（非侵入性，耗时接近0）
· 为什么做：确认问题是否真实，并快速定位大致方向（如资源瓶颈或错误激增），避免误判。
· 操作步骤：
    · 访问已有的监控系统（如Prometheus、Grafana、CloudWatch、APM工具如New Relic或ELK），查看API响应时间的趋势图。重点关注异常点发生的时间段。
    · 检查关键资源指标：CPU使用率、内存占用、磁盘I/O、网络延迟。如果资源利用率突然饱和（如CPU峰值或内存OOM），可能指向代码问题或外部依赖。
    · 查看错误率和请求量：API 4xx/5xx错误是否增加？如果有高错误率，可能上游服务故障或传入参数问题导致重试和延迟。
· 保证不增加耗时：监控数据通常是预聚合和缓存的，查询操作是只读且轻量，对系统性能影响可忽略。
2.分析现有日志（低风险，耗时微增但可控）
· 为什么做：日志中可能记录慢查询、异常堆栈或超时信息，帮助定位具体模块。
· 操作步骤：
    · 使用日志查询工具（如Kibana、Splunk或grep命令）搜索模块的访问日志，过滤耗时超过阈值（如 >500ms）的请求。关键词：slow request、timeout或错误码。
    · 聚焦时间范围：匹配监控中的异常时段，分析请求路径、参数和响应状态。
    · 检查依赖日志：如果模块依赖数据库或缓存（如MySQL慢查询日志、Redis监控），查询这些日志看是否有超时或锁争用。
· 保证不增加耗时：
    · 使用日志采样（如只查询1%的请求）减少开销，如果系统支持，直接读取已缓存的日志索引。
    · 避免启用debug级别日志或添加新日志输出，以免增加I/O压力。
3.检查外部依赖和第三方服务（只读查询）
· 为什么做：API耗时上涨常由下游服务（如数据库、缓存、RPC调用）变慢引起，排查时应优先排除外部因素。
· 操作步骤：
    · 查询依赖监控：检查数据库（如MySQL SHOW PROCESSLIST，但避免在高峰期运行）、缓存（如Redis INFO命令）或外部API（如第三方服务状态页）的性能指标。关注响应时间、连接池使用率和错误率。
    · 网络诊断：使用ping或traceroute（但需谨慎）到依赖服务端点，检测延迟或丢包。优先依赖网络监控工具（如Cloud Provider VPC流日志）的数据，避免主动探测生产环境。
    · 关键问题源：数据库慢查询（如缺少索引）、缓存击穿或限流、第三方服务降级。
· 保证不增加耗时：所有命令基于只读查询（如SHOW PROCESSLIST非阻塞），或在备机执行。若需网络探测，使用监控历史数据而非实时工具。
4.审查近期变更（无需运行时代码修改）
· 为什么做：50%的故障由部署或配置变更引起。排查时检查变更记录，而非直接回滚（回滚可能增加风险）。
· 操作步骤：
    · 检查发布系统（如GitLab、Jenkins）的部署记录：是否有新版本、配置更新（如超时时间调整）或功能开关启用？重点关注变更时间和API耗时上涨的相关性。
    · 对比环境：如果有预发布环境，验证相同请求是否耗时正常，但不在生产复制测试。
    · 依赖变更：外部服务或SDK版本升级是否发生？
· 保证不增加耗时：操作仅涉及元数据查询，不影响运行时性能。
5.临时控制影响（预防恶化，但不直接减少耗时）
· 虽然排查时不修复问题，但可采取措施防止耗时进一步上升：
    · 限流降级：如果API网关支持（如Nginx、Spring Cloud Gateway），调整现有限流规则（如降低QPS阈值），但避免新增规则导致额外计算。
    · 流量采样：在负载均衡层（如HAProxy）启用请求采样，减少低优先级请求的影响。
    · 回滚决策：如果变更审查指向特定部署，考虑在低峰期回滚，但回滚操作本身可能短暂增加负载，需评估风险。
6.关键原则和注意事项
· 不增加耗时的核心策略：
    · 只读优先：所有操作只查询现有数据（监控、日志、配置），不写入或修改系统。
    · 避免高开销工具：禁用profiler（如Java Flight Recorder）、调试器或tracing工具（如Jaeger），它们可能增加CPU开销。
    · 资源约束：在容器化环境（如K8s），查询日志和监控不消耗额外资源；物理机避免运行top或vmstat，而是看历史数据。
    · 团队协作：优先询问SRE或监控团队获取数据，减少直接登录服务器。
· 如果问题根源不明：收集必要信息后（如日志片段和监控截图），在测试环境复现问题，避免在生产深入诊断。
· 后续修复：定位原因后（如数据库索引缺失），修复应在低峰期进行，并添加监控告警以防复发。
2.面：假如现在有类似抢购之类的情况发生，怎样保证系统稳定性
（这个网上答案很多，去找一下看吧，关键在于我只考虑了数据库的使用和配置，不够全面，面试官强调了还可以使用服务器的内存结构提供多级缓冲）
3.这里记不太清了，大概是如果系统出现宕机之类的情况怎么办，我的回答是通过htop，日志查询定位时间等方式解决，面试觉得还可以
HRD面
一般来说不用写这个的，但是这家公司的HRD面比较难，HR和我说通过率大概在20%左右，主要考查你对他们公司业务的掌握情况，性格和学习热情等，所以大家要注意一下，多问问HR关于这方面可能会考察的知识，最好去他们官网，看一下他们业务的api手册（里面有这个api需要的参数），还有一些不常见业务的理解、
面试方式是做题，会给你三道业务题，让你口述或者直接写，会有语文的概括信息题，异常数值的敏感性，常见业务的理解等，最后HR给的review大概是拿了70-80分，主要是语文不太好，概括了两次才过....#牛客AI配图神器#