Kibana时间设置问题

昨天排查生产问题，Kibana的这个时间设置让人很难受，虽然问题的根因还没有定位。今天我决定在家先把这种让人难受的问题先解决掉。一些系统还是用的ELK那套东西，新的已经迁移到SLS里面。网关时间戳GMT时间和Kibana的时间差16个小时，和东八区的时间差8个小时，应用程序写入到Kibana里面的时间是东八区时间。但是Kibana里面Index Pattern的时候差了16个小时。是怎么回事呢？

问题在于写入的@timestamp已经是东八区时间了，Kibana默认时间设置是根据浏览器里面的时区设置的。

Timezone for date formatting
Which timezone should be used. "Browser" will use the timezone detected by your browser.
Default: Browser

默认将通过浏览器获取当前系统时区，并在日志时间上加上这个时区，比如东8区，将在时间上加8小时再展示。而elasticsearch中的日志时间已经经过了时区处理，因此这里的默认处理方式，对以UTC时间记录的日志是正确的，而以本地时区时间记录的日志处理是错误的。

针对这个问题，可以在kibana的setting->advance中，将dateFormat:tz设置改为UTC/GMT即可。

开发为啥要关注这些运维问题？因为当前的模式采取的开发+运维的方式，你负责的系统你负责运维，云团队只提供基本的平台和技术支持，你需要多少服务器，你需要自己预算。刚开始对这种运维方式挺反感的，感觉这种方式安全度不高，开发可操作的空间比较大，容易让开发对生产的敬畏度不够。之前的工作方式就是开发和运维边界比较清晰，因为要去学习linux命令，学习怎么构建流水线和容器相关知识，这种运维方式也有自己的优势，每个团队的项目自己负责，运维只提供技术支持，减少了运维人员，开发可以更好的DevOps。整个DevOps都有整个团队负责，云团队给你提供“水电煤”。

研发流程就这么多，重要的是根据每个公司的现状，把每个节点要执行的过程，检查点和输出物确定完。再用信息化系统实现。高效的研发流程是确保高质量交付的关键。科学的方法+实践+激发人性的善才能让研发效率更高。