带团队几年后，很容易快速判断一个同学是否靠谱。那什么是靠谱？即你把一个事情交给一个人后，完全不用操心后续，因为你知道他肯定能落实，就算中间有困难，他也会及时给与你反馈，然后一起协商后续应该如何快速解决此问题。如果靠谱度需要分级的话，我会将其分为三层：做完、做好、做到极致。但是靠谱度是可以培养的，我认为做好以下几点就基本可以胜出了。
即做事情要站在结果的角度去考虑和解决问题，以终为始，从目标开始考虑需要什么条件，然后主动想办法去创造条件从而达成问题的解决。但是不要把“过程导向”和“结果导向”对立起来二选一，实际上在职场中，结果导向并不意味着不重视过程，恰恰相反，而是要用以终为始的心态，带着清晰的目标，善用3W分析法，去开启和推进做事情的过程。
简单来说就是“凡事有计划，约定必落实，问题早知会，及时报进程，事后须反馈”。闭环思维的培养需要多使用PDCA法则指导自己。
此前，滴滴日志主要存储于 ES 中。然而，ES 的分词、倒排和正排等功能导致其写入吞吐量存在明显瓶颈。此外，ES 需要存储原始文本、倒排索引和正排索引，这增加了存储成本，并对内存有较高要求。随着滴滴数据量的不断增长，ES 的性能已无法满足当前需求。
在追求降低成本和提高效率的背景下，我们开始寻求新的存储解决方案。经过研究，我们决定采用 CK 作为滴滴内部日志的存储支持。据了解，京东、携程、B站等多家公司在业界的实践中也在尝试用 CK 构建日志存储系统。
面临的挑战主要来自下面三个方面：
技术Leader核心工作是让团队拿更好的成绩，日常工作主要是制定方案、推进业务、掌控下属、协助领导等四项内容，本次分享主要分享最基础也是最重要的管理职责：
好几年前的文章了，之前排查问题，随手写的，但是发现其他团队人遇到类似问题没有思路，所以还是发出来，给大家一起解决问题的思路。
ES集群磁盘报警，发现/home/coresave/ core文件导致根目录磁盘被打满，删除core文件恢复，已知这个集群新上线了jdk 17 zgc，排查下jvm为啥core。而jvm core一般有以下几个原因：资源超了（内存、线程数，vma数等），jvm bug（比如指令集）
先去elasticsearch根目录查看core日志，即hs_err_pid_xxx.log，内容如下：
看core原因是因为资源不足（不一定是内存）导致的问题，jdk 17 zgc core后，fatal error 原因与g1 有明显不同，突然不知道怎么去排查了，研究下，思路如下。资源不足原因我们可以在hs_err.log里查看具体的原因，步骤如下：
