# blog **Repository Path**: zstorage/blog ## Basic Information - **Project Name**: blog - **Description**: 这个目录用来保存zStorage微信公众号上的技术博客文章 - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 4 - **Forks**: 17 - **Created**: 2024-02-21 - **Last Updated**: 2025-08-26 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 公众号文章 本目录用来存放zStorage公众号的技术博客文章。 ## 1. 目标 ## 2. 读者群画像 zStorage针对的目标群体，首先是类似于zData X的SE张伟这样的人，或者 MogDB的CTO张程伟，或者跟我们自己类似的存储系统开发人员。也包括，企业IT 部门的存储管理员。他们的特点是: * 对计算机技术理解比较深入，是某一方面的专家；他们可能不是分布式存储系统 专家。但是，他们了解分布式存储的概念，不需要再解释分布式系统是什么。 * 他们对zStorage可能不了解，对Ceph可能也不了解。 ## 3. 排版和插图 #### 3.1. 插图风格 * 统一使用云和恩墨公司的淡蓝色色调的插图。尽量避免大面积使用橘黄色、分红色 不协调的颜色。 * 插图尽量避免使用斜线。斜线看起来很乱，不美观。 * 文章主要在微信公众号上发，要适合收集阅读。如果如果配图字体很小，那么手机 阅读就很困难。或者配图比较宽，那么手机竖屏阅读的时候，会按照比例把配图 缩小也会阅读困难。 * Linux终端命令行文本截图，宽度最多不超过80列。终端背景颜色建议RGB=(64，128，191)， 前景字体颜色RGB=(255, 255, 255)。 #### 3.2. 排版风格 使用秀米进行排版，小结标题使用蓝色原点标记。具体样例参加下面文章： https://mp.weixin.qq.com/s/uXH8rkeJL_JMbKT3H9ZuCQ 标题带有"x."或者“x.y."这种数字标号。在markdown文件中，一级标题使用两个井号， 二级标题、三级标题用4个井号。 #### 3.3. md文件要求 用markdown格式(.md)的文件，提交到本gitee.com/zstorage/blog目录。对.md文件要求如下： * 汉字用utf-8编码； * 文件名用英文，禁止使用汉字文件名；文件名单词中间禁止空格。 * 文件内容禁止使用不可见字符。 * 文件每行最多80个英文字符，最多40个汉字。一个汉字算2个字符宽度。 ## 4. 选题和文风 写公众号文章，目的是通过文章吸引别人关注我们，进而形成合作。如果大家写文章， 只是为了完成任务，那么就达不到这个目的，反而让读者形成了对我们产品的负面印 象。这是我们不希望看到的。 什么样的文章，才足够吸引人呢？ * 观点新颖。首先要有自己鲜明的观点，不能只有说明，没有观点。显而易见的道理， 不必重复。没人愿意浪费时间读你的陈词滥调。 * 结构严谨。文章本身是有故事结构的，章节之间，自然段之间，是有关系的。 所有内容，都是围绕中心论点展开的。 * 论证严密。论证观点的过程，要清晰严密，要符合逻辑。 * 内容充实。文章不能只有空泛的观点，还要有论据。论据可以是自己实验得出的数据， 也可以是引用别人的实验数据。 #### 4.1. 基本要求 我们写zStorage公众号的目的是： * 自我提高。通过文章，对自己的设计思路，做一个相对系统的总结。 * 以技术文章作为载体，跟存储开发人员、zStorage的用户等进行技术交流。通过 文章来表达zStorage的设计理念，也听取同行和客户的不同观点。 * 帮助大家了解zStorage，通过文章帮助zStorage取得商业成功。 文章如果错别字连篇，语句不通顺。上文之间缺乏逻辑联系。充斥着晦涩难懂的 zStorage特有的术语，并且没有任何解释。这样的文章，很难吸引别人读下去。 #### 4.2. 文章选题 * 选题类型 题目可以是zStorage的功能特性设计、zStorage的应用经验、zStorage在某一方面 的性能测试报告、调试经验、存储相关的论文阅读心得，等等。 * 文章选题范围不要太大。 如果题目范围太大，就必须要用抽象的语言才能覆盖这个话题。抽象，就难以理解， 更容易让人感到乏味。提倡选题尽量深，避免太广。 * 文章选题应该尽量与zStorage相关。 也可以选择跟分布式存储相关的，或者跟存储相关的。尽量避免选择跟存储完全 无关的技术。例如，对于zStorage公众号来说，《linux程序员必备之内存管理》 就不是一个好题目。可以写《zStorage如何利用Linux内存管理》。 * 避免选择的题目 (1) zStorage特别严重的Bug。严重Bug我们自己知道就行了，我们内部把它解决 掉，认真反思总结，避免下次再出现同类问题。没必要把Bug拿出来放到zstorage 公众号上展示出来，吓唬用户，给竞争对手提供攻击自己的武器。（2）打算申请 专利的技术，先申请专利，等到专利申请流程可以公开的时候，在来写成公众号 文章。 #### 4.3. 内容充实 文章需要有充实的内容，要有新鲜的信息传递给读者。让读者从你的文章中， 能够获取到他们之前不了解的事实、新的观点、新的知识和技能。如果只是商业 宣传，充斥陈词滥调和自我吹嘘，那么就是浪费读者时间，也浪费自己的时间。 要尽量避免纯粹的说明文。如果只是告诉读者，我的模块是这么设计的；而不讲 为什么这么设计；也不讲，在决定这么设计之前，还做过哪些权衡选择；那么，读者 就会用脚投票，打开之后，读10秒就会把你这篇文章关掉。 #### 4.4. 故事结构 公众号的文章，不是词典，不能是一个一个词条的罗列。公众号的文章，要当作 “侦探故事”来写，要有故事情节，要写的引人入胜，这样才会有人看，才有人自发 的在朋友圈传播。一篇文章写的好不好，点赞数量、转发数量、再看数量，是重要 评价标准。 多讲故事，少讲一点道理。尽量让读者自己得出结论，而不是强迫读者接受 你的结论。 写文章就像是带着读者去旅行，要实现计划好路线和景点，特别是从哪里开始，到 哪里结束。要把zstorage公众号文章当作侦探故事来写，要设计引人入胜的故事情节， 尽量避免枯燥乏味的说教。 #### 4.5. 多讲为什么 文章应该多讲“为什么”，少说“是什么”。避免平铺直叙描述zStorage是怎么 做的。要努力交代清楚“问题是什么"，以及“有哪些可选的解决方案”，以及这些方案 各自的优缺点是什么。也可以讲其他系统是怎么做的，有什么优点，以及可能有哪些 问题。我们选择的依据是什么。我们选择这个方案之后，效果如何，等等。 #### 4.6. 用数据说话 尽量用实测数据来展示设计优化的效果。网络上有很多空想的技术博文，价值并不大。 空对空讨论，看似很有道理，但是禁不住实测验证。有了实验数据，才说明文章作者在 这个问题上做过深入思考，也才更有阅读的价值。 #### 4.7. 不要自卖自夸 避免直接的、空洞的夸耀zStorage，这会引起读者方案。如果读者发现这篇文章是 广告软文，那么他们读下去的兴趣会大大降低。 “我有个想法，对我们双方都有利”，要尽量以这种心态（姿态）来写文章，避免 表达“我有多了不起”。 ## 5. 评分标准 1次阅读1分，1个点赞100分，1个在看100分，1次朋友圈分享100分。 从微信公众号后台可以下载每篇文章的详细分析数据，数据存放在excel文件中。下列 单元格中数据参与评分计算： * C5 -- 阅读(次) * C6 -- 平均停留时长(秒) * C7 -- 完读率 * C8 -- 阅读后关注（人） * C9 -- 分享(次) * C10 -- 在看(次) * C11 -- 点赞(次) * C12 -- 赞赏(分) * C13 -- 评论（条） 评分计算公式为： ``` score =(100*SUM(C8:C13)+C5) * (0.5 + C7/0.5) * (0.5 + C6 / 180) ``` 对评分规则的解释如下： * 阅读次数（C5），单次阅读算1分。 * 阅读后关注（C8）、分享（C9）、再看（C10）、点赞（C11）、评论（C13），等这些 指标，单个算100分。也就是说，1次分享，或者1次阅读之后关注，跟100次阅读分数一样。 * 阅读完成率。这个用来计算一个完成率系数，用这个系数乘以以上各项指标的得分， 来调整最后得分。计算方法为：Rate-complete = 0.5 + (完成率 / 0.5) 也就是，完成为0.25，这个系数的值为1。用这个系数调整之后，分数不增不减。 * 平均停留时长。同样也用来计算得分调整系数，平均阅读时长为3分钟（180秒），系数 为1.0。系数最低为0.5。 ## 6.存放位置 请每个人注册一个gitee账号，在下面这个目录中，以自己 名字创建一个子目录。请大家写完之后，直接提交PR，提交到这个上面。 https://gitee.com/zstorage/blog/ (结束)