一个纯正程序员的啰嗦
在 Java 中打印当前线程的方法栈，可以用 kill -3 命令向 JVM 发送一个 OS 信号，JVM 捕捉以后会自动 dump 出来；当然，也可以直接使用 jstack 工具完成，这些方法好几年前我在这篇性能分析的文章中介绍过。这样的需求可以说很常见，比如定位死锁，定位一个不工作的线程到底卡在哪里，或者定位为什么 CPU 居高不下等等问题。
现在工作中我用的是 Python，需要线上问题定位的缘故，也有了类似的需求——想要知道当前的 Python 进程 “在干什么”。但是没有了 JVM 的加持，原有的命令或者工具都不再适用。传统的 gdb 的 debug 大法在线上也不好操作。于是我寻找了一些别的方法，来帮助定位问题，我把它们记录 [……]阅读全文
除了主要内容——工具和实践，这篇文章也对 “谈谈 Ops” 系列做一个汇总，提供一个访问入口。之前几篇，从一个纯粹 dev 狭窄的视角，谈了谈自己对 Ops 的一些认识：
在往下继续以前，如果没有看过前面的文字，不妨移步阅读，因为上面的内容对下面的内容做了一定程度的铺垫。
现在在写的这一篇文字，我准备是最后一篇，主要谈论这样几个事情：一个是工具，另一个是实践。我依然还是从 dev 的视角，而不是从一个专业运维的视角来记叙。
工欲善其事，必先利其器。我在主要且通用的工具 [……]阅读全文
作为普通的开发人员，我们会遇到对于时间分配的思考，没有金标准，只有某些看起来也未必靠谱的 “最佳实践”。不同人眼中对于整体的时间分配也有自己的看法，这篇文章旨在探讨其中的一两种情况。
Ops 的事务类型
Ops 的事务很多很杂，首先要明确一点的就是，Ops 远不止 oncall，远不止线上产品维护。整个软件工程流程中的配置、部署、环境搭建、升级、打补丁，甚至问题定位、故障排查等等，都或多或少可以算作 Ops。
记得在读书的时候，老师给我们把日常事务划为四个象限：紧急重要、紧急不重要、不重要但紧急，以及不重要不紧急。Ops 和一般软件开发活动在这四个象限的分布上来比较，更多地，会偏重于 “紧急 [……]阅读全文
第二部分，我想谈一谈流程，依然来源于我的理解。Ops 的实践上面，有两部分内容紧密结合，不但共同显示了 Ops 的生产力，也在相当程度上体现了 Ops 的技术水平。这第一部分就是流程，也是今天要说的内容，另一部分是工具（也包括和使用工具相关的技能），下一次再说。
我认为 Ops 可以分为几个层次，最次的的一层，其特点是重度依赖于的人的直接 “操作”。风险管理、因果行为，都通过流程来统一把控，并且遗憾的是只有流程——除了它基本没有可靠有效的工具，或是其他办法。
其实，流程本是个好东西。有时候某些工程师被散漫和自由主义惯坏了，听到流程就反感。事实上，流程在很多情况下都有着举足轻重的作用。它们很容易控制[……]阅读全文
偶然地，在会看这些年写的文章的时候，发现涉及到软件工程方方面面的内容，但是关于 Ops 的内容却非常少。我觉得这是不太合适的，因为在实际工作中，Ops 显而易见地占据了一大块比重。于是我调整了分类目录，增加了这个单独的分类，并且这一次，我想零零散散地讲一讲我关于 Ops 的一些经历，以及关于 Ops 的一些观点。
所谓 Ops，指的就是 Operations，在中文翻译上看，我觉得 “运维” 这个词可能是最恰当的。作为一个软件工程师，Ops 有时会特指 DevOps，关于它的定义，在维基百科上有这样一张图片，我觉得基本正确地描述了 DevOps 涵盖的内容（见右侧图）。
可以看到三方面的内容，可是，由于我们会把 [……]阅读全文
最近在搭建开发环境，大致的布局是这样的：一个专门的数据库 VM，一个用于编译和代码执行的 VM（dev virt，装的 RedHat），还有用来写代码和运行这两个虚拟环境的 Mac（local）。这里我需要一个工具，可以满这样的需求：
我把我的解决办法简单记录在这里。在接下去记录之前，需要回答这样两个问题：
[……]阅读全文
经常用到一些命令，还总是忘掉的，就简单列在这里。总是现查也挺麻烦的。
Linux：
[……]阅读全文
最近的工作总是在 EMR 上跑 Spark 的 job，从代码完毕到测试完毕的过程是这样的：
1. 本地测试：
构建 -> 本地 UT -> 观察分析结果，这一阶段可以发现逻辑问题
2. EMR 上执行测试：
上传最新构建到 S3 -> 准备 EMR 资源（包括计算资源和数据）-> 在 EMR 上执行 Spark job -> 观察分析结果，这一阶段可以发现在数据量较大的情况下才出现的问题
3. Workflow 集成测试（这个 workflow 是公司内部的一个管理 job 的工作流系统）：
&nb
[……]阅读全文
最近看到这篇文章 《小伙伴们手滑集》，觉得感慨很多，强烈推荐大家阅读。比如这样的例子：
UPDATE 没有 WHERE 条件
而我则经历过 delete 没有写 where 条件的惨剧，这个惨剧是某些 case 下面代码调用触发的，不是手动执行 SQL 发生的。
还有臭名昭著的，我没有经历过，但是我有不止一个同事干过这样的事情：
rm -rf
都只是手稍稍地温柔地 “滑了一下” 而已嘛……
这些事情我觉得一下子很亲切，似乎全世界的软件工程师都是如此得同一。
出的事故多了以后，变得战战兢兢，如履薄冰，尤其是回车键这样的敲击，似乎总是带着颤抖落指。
还有这篇文章 《让自家系统瘫痪，这事我也干过》，讲了一个关于使用 tr
[……]阅读全文
在这里可以找得到这些工具的列表，虽然官网上免责声明为 “The tools described in this section are unsupported and experimental in nature and should be used with that in mind. They might not be available in future JDK versions.”，但实际上这些工具还是非常有用的，尤其可以站在 JVM 的角度来定位问题。我在此简单罗列一些常用的工具和命令，以及相应的执行结果示例。如果你经常和 JVM 打交道，最好对这些工具的常用命令熟记。
jst
[……]阅读全文
JDB
JDB 是基于文本和命令行的调试工具，Jikes 在 JDB 的基础上提供了 GUI。熟悉 JDB 还是有价值的，很多情况下需要我们在命令行下完成简单的 debug 问题定位。
jdb -classpath bin com.xx.Example jdb -connect com.sun.jdi.SocketAttach:hostname=myhost,port=8000 jdb -connect "com.sun.jdi.CommandLineLaunch:main=Hello 1 2 3"
我们可能更熟悉使用下面这样的方式来进行调试，但本质上就是在使用 JDB：
-agentlib:jdwp=tran
[……]阅读全文
致命错误出现的时候，JVM 生成了 hs_err_pid<pid>.log 这样的文件，其中往往包含了虚拟机崩溃原因的重要信息。因为经常遇到，在这篇文章里，我挑选了一个，并且逐段分析它包含的内容（文件可以在文章最后下载）。默认情况下文件是创建在工作目录下的（如果没权限创建的话 JVM 会尝试把文件写到/tmp 这样的临时目录下面去），当然，文件格式和路径也可以通过参数指定，比如：
java -XX:ErrorFile=/var/log/java/java_error%p.log
这个文件将包括：
[……]阅读全文
在很多情况下，运维占到软件成本的大块，专业的运维人员更是不好找。这样的人需要熟悉操作系统、网络以及数据库。而运维又是一件很苦逼的事情，成了算是软件写得好，研发团队的功劳；败了就得彻夜坚守岗位提供支持，不可控的因素太多。是上游团队的软件质量太差吗？
我在 09 年的时候曾经到过局方，呆了挺长一段时间，既是开局，也做运维的工作，和运维的工程师朋友一起蹲机房、守夜、切设备，知道其中无比的苦楚。很多情况下，版本的更迭、割接，都要在凌晨完成，需要仔仔细细地测试；不幸失败了还需要立即回滚，然后陪着项目组等领导骂，等新版本或者补丁到来，再重复熬夜的这段过程……
不如大胆一些，解雇你那些抱怨不止、喋喋不休的运维
[……]阅读全文