API单位误解造成的严重故障
每个软件在运行时也不可避免的会出现各种各样的故障,严重的故障会使得用户对网站的信任度下降,甚至产生严重的社会影响和经济损失,在"精神号"登陆火星之前,还有一个代号为"雅典娜"的火星车在尝试登陆火星时失败了,损失了上亿美金,而最终排查到的故障原因仅仅是两个不同的团队对使用的API的单位的理解不一致,这里也将给大家分享一个类似的API单位理解错误造成的严重故障。
故障的现象是某个重要的系统功能页面访问直接报错,报错的初步原因是被系统被限流,唯一保留的现场的信息是内存的dump信息。
在拿到内存dump信息的情况下,需要用什么样的思路和工具来揭开造成故障的根本原因,定位到相应的代码呢,这需要对故障产生的背后原理清楚,同时要求对各种排查工具非常熟练,很多时候排查故障的能力的差别就仅仅在工具的使用上,这个部分将详细的为大家分享最终定位到问题代码的过程。
故障的排查和解决过程就像是一场争分夺秒的战争,排查的技巧和经验在这个时候特别的重要,最后将给大家奉上常见的Java问题排查的工具箱,例如jmap、jstack、MAT、btrace等等利器。
资深技术专家,目前就职于阿里巴巴集团—技术保障部。
2007年底加入淘宝,2008-2010年负责淘宝服务框架的设计与实现,此服务框架是淘宝3.0架构体系中的重要组件,在淘宝大范围使用,2011年每天承载的服务请求量为300亿+;
2009年与同事共同出版《OSGi原理与最佳实践》一书,2010年出版《分布式Java应用:基础与实践》一书;
2011年负责HBase在淘宝的落地,目前HBase在阿里的各家公司使用广泛,为海量数据读写的业务提供了支持;
2011年下半年至今主导T4产品(基于lxc),目标为大幅度的降低淘宝的运维成本;
2013年转为运维,着力关注运维领域,主要涉及的为可维护性、稳定性、性能、成本、软硬件结合,并根据发展需要推动系统结构演变。