我觉得对于一些小公司和初创型公司来说，你要关注的是你要出现了误操作怎么办？你可能认为你的数据不需要备份到OBS这种程度，但你可以使用Cassandra本身自带的特性，你可以把配置文件里的配置项都打开，如在做TRUNCATE的时候做自动快照。这我觉得是Cassandra的对运维来说非常好的一个的地方。如果你真的误删了，其实硬盘上并没删除。你仍可以通过快照很快地进行恢复，这也不需要什么太大的成本。不管是开发人员、还是运维人员，我强烈建议大家在后面使用的时候打开这些开关，防止一些极端的情况。
下面列了一些我们数据库现网的一些问题管理中的使用规则。有些开发同事可能认为这些规则限制了他，但这些机制其实是Cassandra本身的一些约束。如果你突破这些约束，你的现网可能会出现一些不可预知的问题。假如你在设计schema阶段引入了问题，到后期一旦出现问题，在短时间内是无法解决的。你要重新优化schema，做出新的版本，这会花费很长的时间。
因此在我们这里会先立规则。大家在开发的同时，一定要知道这些规范，在开发阶段就要减少这些问题。在我们华为，如果你有业务要接入Cassandra，你要按照这些规则自检一下，我们做一个简单的评审，如果没有问题，我们就会给你提供一些建议方案。如果你的分区键在你的表结构Schema设计上存在一些问题，我们会给出一些建议，让你优化之后再接入现网。如果后期实在还是有漏掉的，我们通过一些巡检，把这些问题找出来，会通知到业务，跟业务一起去做一些优化。
我看到DataStax公众号上面有一篇文章也讲的非常详细，有哪些注意事项。我认为每个开发的同事，包括运维的同事都要认真熟读一下。
这其实是我们一个热Key的案例，我就不详细讲了。其实你在设计Schema的时候便要考虑你的场景是否存在热Key，能规避则尽量规避，如果规避不了则需要靠多级缓存。如果热Key的话加Redis可能还不够，因为Redis也是单点的，可能还需要考虑本地多级缓存。或者用redis本身的这种前端proxy做负载均衡才能解决问题。热Key这种问题是比较难处理的，我估计很多开发人员都会所面临这种问题。但你要避免热Key出现在Cassandra中，如果出现了，对Cassandra影响会比较大，甚至会影响正常Key的访问。因此热Key在设计阶段一定是要规避的。
我们有这么大的规模，因此我们经常有一些变更，需要一些数据库的自动化平台来帮我们提升一些效率并降低一些风险。我们的DBA人数有限，可能不能完成这么多事情。
我们现在有一个CQL的审核模块，它会自动把你的那些你看到那些DDL脚本解析出来。如果是非高危字段，我们可以让你走自动化变更流程。如果是DROP这样高危的删除字段操作，我们是不会让你自动在现网上运行的，要走另外的流程。对于那些刚开始的，尤其是有些公司没有运维的同事，你们的变更里如果有高危操作你一定要先识别出来。还要考虑操作前有没有备份，出现极端情况下是否有可挽救的措施，这些是一定要注意的。
最后我们介绍下监控，因为前面看到线上的一些朋友在问监控怎么做，我们也分享一下我们的经验。其实我们比较简单，就像一些技术指标监控，这种大家都会。很多开源软件都很方便，网上的文档也很多，像早期的Zabbix和现在的Prometheus。包括Cassandra内部的JMX，在采集metrics时都有现成的模版，Prometheus也都有相关的支持。我觉得大家可以把这些监控都加上。我们后面也有自己加的监控，比如说我们自己在驱动里面会把一些时延成功率等这些信息打到日志里，然后上报到我们的日志平台中做一些监控。