看新闻说有个涉嫌破坏计算机信息系统的嫌疑人被押解回国了。想聊点不一样的——这罪和咱们常听见的盗号、勒索、窃密其实不是一码事。它盯的不是数据丢没丢，而是系统还能不能干活。让服务器趴窝、业务停摆，这就够得上立案。这玩意儿在英文里叫 availability，是系统能不能服役的硬指标之一。
搞过工程的人都懂，制造这种破坏的技术门槛低得离谱。一行写反的条件判断、一个越权的清理脚本，效果上跟精心入侵没两样，可成本差着十万八千里。所以法律才单独把"破坏"拎出来设罪，因为数字社会里"系统跑不跑得动"和"数在不在"分量一样重。其实
真正棘手的永远是那层纸：你是手滑还是蓄意。好在日志不会撒谎，audit trail 里每一步都钉得死死的。写 fatal bug 的人满街都是，但"明知会瘫还动手"和"我哪知道会这样"之间，隔开的就是主观故意。法官抠的，恰恰是这一毫米。
楼主最后讲的那"一毫米"，我瞧着是最磨人的。audit trail再清楚，钉得死每一步动作，也钉不死写代码那人当时心里究竟怎么想的。
楼主说日志把每一步都钉死，这点我稍微有点不同看法。日志确实能还原"发生了什么"——哪个账号、什么时间、执行了哪条命令，这些都清清楚楚。但它还原不了"为什么"。那个清理脚本是人手滑点的，还是憋着劲要搞瘫系统，日志本身给不出答案。
真要抠主观故意那毫米，靠的往往是外围的东西：这人什么岗位、有没有权限说明、之前有没有被约谈过、同类操作正常流程长啥样。光看 audit trail，最多证明动作存在，证明不了"明知"。所以那层纸没帖主说得那么容易被日志捅破，法庭上真正扯皮的，恰恰是日志之外那一截。你们几个搞安全的，实际案子里这一步一般怎么认定的？
关于"让服务器趴窝就够得上立案"这句，我想补个硬门槛。2011年两高出了个办理危害计算机信息系统安全刑事案件的司法解释，把刑法286条的"后果严重"量化了：造成十台以上系统的主要软硬件不能正常运行，或者造成经济损失一万元以上，或者为一万以上用户提供服务的系统瘫痪，才够得上是"后果严重"。所以"业务停摆"到底停到什么量级、波及多大，是有具体标准的，不是一瘫就立。
你讲的 availability 视角我挺认同，数字社会里"能不能服役"和"数在不在"确实一样要紧。只是立案那道线，真抠起来比一般说法要具体得多。
你说的"日志不会撒谎，audit trail 里每一步都钉得死死的"，我倒觉得得打个问号。日志能钉死的是 what happened，谁、什么时间、跑了哪条命令，这部分确实客观。但主观故意（mens rea）这事偏偏是日志还原不出来的。“明知会瘫还动手"和"真没想到会这样”，法官不是从日志里直接读答案的，得靠动机、事前事后行为这些 circumstantial evidence 去推。换句话说，日志解决事实层，intent 那一毫米才是真难啃的骨头。实务里见过不少日志一清二楚、可故意与否吵了半年的案子。
有个硬杠得补一下：趴窝不等于够立案。刑法那条卡的是"后果严重"，司法解释对瘫了多少系统、牵连多少用户、经济损失多少都有具体数。小范围的误操作，够不上刑事，按生产事故处理就完了。其实
日志不撒谎这话方向对，但别太乐观。审计轨迹能证明"发生了什么"，证明不了"你盼它发生"。同一行越权清理，运维手滑和维护窗口蓄意，从日志看动作一模一样。法官抠的那一毫米，靠的是动机、事前沟通、时间线这些旁证去补，不是单看 audit trail 就能钉死。
顺手翻了下刑法286条，楼主说这罪"盯的不是数据丢没丢"其实说得稍窄——同一条里专门有一项，是对系统里存储、处理的数据和应用程序做删除、修改、增加操作，这一项盯的恰恰还是数据，只是它卡的是完整性、不是有没有被偷走。所以准确讲，破坏罪管的是"跑不跑得动"加"数完不完整"两件事，availability 和 integrity 都在里头。
年轻时也手滑过…，一行清理脚本把跑着的业务清了。后来才懂 availability 这几个字有多沉。
楼主那句"日志不会撒谎"很实在，但得补一点：audit trail 钉死的是行为和认知，要从里头推出"明知会瘫还动手"的主观故意，靠的还是司法推定，不是日志自己把话说完。刑法286条这个罪本来就是故意犯，纯过失把系统搞瘫一般够不上。
补个硬指标：286条立案得是"后果严重"，不是服务器一瘫就够。司法解释里经济损失过万、或十台以上系统跑不动才算数。你聊的"主观故意"那毫米才是真难点。
你提到的"明知会瘫还动手"和"我哪知道会这样"之间那毫米，我看着挺心惊的。其实分清楚手滑还是蓄意，倒不全是技术层面的事，更多还是得看人当时心里到底怎么盘算的。不过日志不会撒谎这点确实让人踏实，系统出了岔子至少还能翻出清清楚楚的痕迹，不像生活里有些事，真要说个明白反倒最难~
你最后抠的那"一毫米"其实比前面整段都难。日志确实把"发生了什么"钉得死死的——哪个账号、几点、跑了什么命令、波及哪些节点，链条清清楚楚。可法官要判的是"明知会瘫还动手"，这东西偏偏不在日志里。日志记动作，记不下动机。同样一条越权清理脚本把生产库清了，从日志看两种情形一模一样…，差别全在动作之外：他当时在群里说了什么、有没有人提前警告过、他这个岗位本该懂还是装不懂。这些才是那一毫米落在哪里的依据。
另外想补充的是，"系统还能不能干活"这个标准本身，比"数据在不在"要模糊得多。数据丢了是离散的，要么丢要么没丢。可 availability 是连续的——慢到什么程度算趴窝？半夜两点瘫半小时，和早高峰瘫半小时，能一样吗？嗯嗯立案门槛划在哪儿，工程上并没有天然刻度，最后还是人来定。所以破坏这个罪名真正落地时，技术指标给的是证据，兜底的是一整套情境判断。
你举的那行写反的条件判断特别真实，工程里这种事太常见了。话说回来，真出了事，光看日志的人最容易被那串干净记录骗了，以为板上钉钉，其实动机那块一直是空的。
看到楼主说那"一毫米"的主观故意，我倒想起早些年单位里一档子事。有个年轻同事跑清理脚本权限设宽了，半夜把业务库好些临时表清了，第二天一开门全瘫。别急日志清清楚楚，他每一步都留了痕——可你说他是蓄意还是手滑？他自个儿都懵，纯粹图省事没多想。
audit trail钉得死，钉的是"做了什么"，钉不出"当时怎么想"。法官抠那毫米，不是抠字眼，是除了问本人看动机，旁的证据本来就薄。真要防，靠的不是抓人，是让那行写反的判断根本递不出去。
audit trail 那句我得补一刀。日志钉得死的是"做了什么"，不是"为什么做"。一行写反的条件判断，trace 里清清楚楚，但它到底是手滑还是蓄意，光看日志拼不出来。最后法官抠的主观故意，靠的是动机、事前聊天记录、还有这人到底懂不懂，这些全是日志之外的东西。所以"日志不会撒谎"只对了一半，它只是不撒谎，但不说话。