简述

“对数据要有敬畏之心”这个主题是同事在一个早会分享时提出的，却直接引起我心中的共鸣。前几年各种删库跑路事件、Facebook宕机事件仍不绝于耳，虽然大家将“删库跑路”当作一个调侃与谈资，但上升到“对数据要有敬畏之心”的高度，作为运维我们就要居安思危，防患于未然。

数据的定义

从运维的角度，数据不是独立存在的，它存在于日常运维过程中的各个环节，如例行维护、变更、故障处理等。因此如果我们只考虑数据本身则意义不大，要从数据存在的各个环节去分析。

在此我们将其大体概括为：

数据备份
文件系统+例行维护
数据库
大数据
业务版本发布
需求变更

数据备份

从数据安全的角度出发，我们最先想到的肯定是数据备份，下面我们来看下数据备份的几个关键点。
首先，根据备份空间和从备份恢复的速度允许的情况下，我们可以将数据备份分为本地备份和异地备份（不考虑多机房容灾）。其次，无论是何种备份方式，我们都需要考虑备份保存周期，因此无规则限制的归档会带来存储成本的不断升高。最后，针对数据丢失或误删等各种场景，我们需要确定就是备份哪些内容。

对此我们总结需要备份的内容如下：

系统级配置文件
内核参数、hosts解析、crontab计划任务、环境变量、防火墙等
应用级配置文件
nginx、java应用、中间件、dns等
日志级数据
应用日志、nginx日志等
数据库备份
binlog日志、逻辑备份、配置文件、慢查询日志

如果你还没有思路，看参考以下这篇文章：

ansible自动化：备份管理实践
https://blog.csdn.net/yanggd1987/article/details/118943961

文件系统+例行维护

和文件系统联系最紧密的莫过于日常例行维护了，如磁盘清理、文件处理等所有与数据丢失风险相关的操作。当我们在例行维护过程中，运维必须精神高度集中，非常清晰的注意每个指令，执行危险操作时可以和同事进行二次确认。

操作文件系统虽然都是简单命令，但也是有窍门的，在此给大家推荐下。

【运维小贴士：巧用Linux冒号命令，实现rm防误删】
Linux系统中冒号(:)在bash中是一个內建命令，而不单纯是一个分隔符，它的主要作用是空命令、参数扩展、重定向、注释等。
我们可以使用其参数扩展特性实现rm的防误删功能，下面我们来通过实例讲解下其用法。
格式： ${parameter:-test}
功能： 如果parameter没有设置或者为空，替换为test；否则替换为parameter的值。
命令： rm -rf ${dest:-test}
用法： 当变量dest为空时，删除test；当变量dest不为空时，删除test
用例： rm -rf /$dest。当变量dest没有设置或为空时，则命令变成rm -rf /，这将误删系统根目录，导致系统崩溃。
改进： rm -rf /${dest:-test}，当变量dest没有设置或为空时，会使用test代替，则命令变成rm -rf /test，删除此目录不会产生任何影响。

除了以上方法，如果我们的服务器都使用堡垒机登录的话，那么福利来了。我们可以使用堡垒机自带的命令过滤功能，禁用操作系统的危险命令。

数据库+大数据

数据库和大数据都作为基础数据，虽然有单独的DBA和大数据运维对其负责，但是我们仍可以借鉴堡垒机的命令过滤功能：

对数据库操作过滤，如：drop、truncate、delete等
对大数据操作过滤，如：hdfs dfs -rm等

除了堡垒机的助力，我们还是需要从标准化流程出发，使用工具进行规范化管理。例如数据库可以使用Archery SQL审核查询平台，而大数据生态由于组件较多，可能无法找到一个统一的管理工具，这个我没有太多的经验，就不在此造次了，但是做好数据备份以不变应万变是必须的。

业务版本发布

业务版本发布绝对是运维工作中紧张又刺激的一项工作了，导致发布失败的原因也很多：

配置文件混乱
多环境污染
git分支管理混乱
版本发布比较随意
缺少测试环节，如回归测试、冒烟测试等
等等

导致版本发布的原因很多，我这面只是列举了一部分。解决这部分问题需要研发、运维、测试的多方面配合，也就是我们耳熟能详的DevOps。

我们从代码托管开始梳理：

代码管理必须严格，按功能区分分支，不能随意合并代码至master；
按环境区分配置文件，以免混淆；
测试、生产等环境最好严格的物理隔离或逻辑隔离，避免环境互通；
版本生产发布前，需要经过严格的功能测试；
确定统一的版本发布日，非发版日严禁变更；
标准化的版本发布流程，实现参数化自动版本发布；
屏蔽/回复发版过程中的告警，实现更精细化的监控；

以上几点不是只靠运维就能解决的，而是需要规范+流程+研发/运维/测试+工具的整体配合。
常见的开源组合如下：Jira+Jenkins+Git+Sonar+Pipeline+监控。

需求变更

生产无小事，生产故障很可能就是因微小的变更操作导致的。在这方面我曾经的基础运维同学和DBA同学都吃过亏，就是一个很平常、甚至有过很多实操的动作，触发了一个bug，进而影响业务。

为什么要把需求变更单独拿出来讲，因为这是一个很容易让人忽略的点。对于不可预知的事情，我们必须提前做好预案：

确定变更操作影响的业务范围
通知相关责任人，确定变更关键节点
确定变更方案及具体操作步骤
做好数据备份及数据恢复方案
确定变更时间，避免业务高峰期

通过预案可以更充分的暴露风险点，帮助我们更好的应用突发问题。

总结

数据无处不在，数据风险也就如影随形，因此运维要对数据有敬畏之心，这和运维经验是否丰富无关。要想做到数据的安全性，我们需要一直保持警惕性。

运维：对数据要有敬畏之心相关推荐

运维大数据可视化分析平台来了，枯燥运维数据也可以生动起来
数字时代监控运维系统数据量暴增,指标.日志.代码堆栈.网络数据包等等时间序列数据从每天几百兆采集量膨胀到每天上百GB,上TB.由于故障总是偶发,而监控数据在故障发生回朔时才更有价值. 如何利用这些低价 ...
中国民生银行：智能运维引领数据中心数字化转型
今天我演讲的题目是<智能运维引领数据中心数字化转型>,跟大家分享民生银行在智能运维领域的探索和实践. 01 数字化转型,运维新挑战金融行业是对信息技术应用最为广泛和彻底的行业.首先,我从 ...
实践：在运维大数据这事上，Apache Kylin比ELK更擅长？
题图: from Zoommy 记得十年前,我曾问过一名应用运维工程师,如何用两个关键词描述下自己的日常工作? 他居然不假思索,略带调侃的回答我, "背锅" 与 "惊醒& ...
运维宝典 | 数据千万条，备份第一条，数据找不回，老板两行泪
开工第一天,请带着你的回忆看下文,想想你这些年删过的库,被删过的库... 数据库备份是个老生常谈的话题,看似很简单,但在实际操作过程中,运维人员往往会遇到这样或那样的"坑". 数据 ...
运维日志数据备份同步的几个方案
博客链接 https://uublog.com/article/20170317/ops-log-backup-rsysnc-sersync-inotify-tools/ 最近公司有这么一个需求.某E ...
tidb load data file 失败_TIDB运维之数据导入与导出
本文章仅针对4.0.0版本. 1. 介绍: TIDB使用Dumpling工具进行数据导出, 使用Lightning工具进行数据恢复. 导出时直接使用Dumpling工具即可导出, 导入时需要先启动ti ...
KingbaseES V8R6集群运维案例---数据块故障自动修复（auto_bmr）
案例说明: 在Oracle11.2版本之后,DataGuard 若搭建实时应用日志的物理备库,那么在主库数据文件少量坏块的情况下,可以利用ABCR技术快速修复坏块. Starting in Orac ...
运维mysql数据库面试题_运维面试题之数据库
mysql篇: mysql主从复制原理? mysql的复制是基于3个线程 1.master上的binlog dump线程负责把binlog 事件传到slave 2.slave上面的IO线程负责接收bi ...
数据中心的敏捷运维之路
随着数据中心的建设规模越来越大,出现了很多大型,特大型的数据中心.这些数据中心往往拥有数万台的服务器规模,再加上互联的网络设备.防火墙.负载均衡等设备,一个大型数据中心需要管理同时运行的几万台设备,并 ...

运维：对数据要有敬畏之心

简述