基于node.js 和hexo框架搭建博客系统

在搭建系统的部分中,也有一种比较简单的方式去搭建属于自己的博客系统。具体实现部分的如下,使用命令。

1、下载node的框架,用于做为博客系统的基础
npm install node.js 

2、切换下载源,使用指向淘宝镜像

npm install -g cnpm --registry=http://registry.npm.taobao.org```

3、下载博客框架hexo

cnpm install -g hexo-cli

4、建博客的文件路径
/Users/tom 目录下 使用命令 mkdir blog

5、进入文件夹目录下安装博客框架
cd blog  进入博客,使用命令sudo hexo init,就能实现下载完成,命令ls -la 可以查看下载的内容

6、在根目录下启动博客
使用命令 sudo hexo s,就能启动博客。本地访问地址是http://localhost:4000/ ,占用本地的端口号是4000,如果想改端口号,使用命令sudo hexo s -p 5555

7、hexo官网的命令
在官网中使用的命令有,创建博客hexo new "My New Post" ,启动命令hexo server ,配置文件更新hexo generate ,远程部署hexo deploy
回到命令行按住Ctrl+C退出。所有文章均以.md格式保存在/source/_posts我们可以在此目录下删除或添加文章。

2023/12/12 posted in  杂谈

语雀和速度赛跑的8小时,我们学习到了什么?

10 月 23 日 14 时左右,蚂蚁集团旗下的在线文档编辑与协同工具语雀发生服务器故障,在线文档和官网目前均无法打开。

事情虽然已经过去了有几天,现在回过头来看整个事情,梳理这其中的一些关键点,看看哪些是能在其中学习到一些知识的。

1 简述整个事件

从时间线上分析:

  • 14:07 数据存储运维团队收到监控系统报警,定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线;
  • 14:15 联系硬件团队尝试将下线机器重新上线;
  • 15:00 确认因存储系统使用的机器类别较老,无法直接操作上线,立即调整恢复方案为从备份系统中恢复存储数据;
  • 15:10 开始新建存储系统,从备份中开始恢复数据,由于语雀数据量庞大,此过程历时较长;
  • 19:00 完成数据恢复,同时为保障数据完整性,在完成恢复后,用时 2 个小时进行数据校验;
  • 21:00 存储系统通过完整性校验,开始和语雀团队联调。
  • 22:00 恢复语雀全部服务,用户所有数据均未丢失。
    这些内容梳理在语雀官方的故障公告中已经有提及到的:

[!note] 这是公告链接:https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw

2 语雀的处理思考

这次的宕机,给作为技术人员,运营人员,以及个人都会有不同的思考。
在技术上的具体宕机的细节,其实外人无从知晓,不过从故障的公告中,能看到语雀团队在技术上的一些细节。
以下是关于语雀公告中提及到的他们的解决方案:

1、升级硬件版本和机型,实现离线后的快速上线。该措施在本次故障修复中已完成;
2、运维团队加强运维工具的质量保障与测试,杜绝此类运维 bug 再次发生;
3、缩小运维动作灰度范围,增加灰度时间,提前发现 bug;
4、从架构和高可用层面改进服务,为语雀增加存储系统的异地灾备。

在这个公告中, 其实能看到的几个解决方案,也是在技术实现和运营中经常会使用到的。
升级硬件的处理。在测试开发环境或者是前期的用户体量比较小的时候,大多是觉得基本的硬件能满足条件就行,基于研发成本和维护成本,大概率不会将硬件的配置升级的很高,去应对可能不会经常出现的事故。

在测试和BUG寻找上,特意有提及到了两种改进的意见。作为开发,经常也会遇见语雀中的形似问题,自己开发环境,测试环境都是能正常运行的,实际上到了生产环境上,各种问题就层出不穷,只能说现实的环境远比理想更加的恶劣。

对此来说,也正如语雀那样,通过在测试阶段更多的增加更多对现实生产环境的模拟,更早的将问题暴露出来,及时解决,避免在生产中造成更大的问题。

除开对硬件和问题流程的优化上,另外一个对技术和资金要求比较大点就是,在软件技术层上的优化。 对于这样一个用户和数据量比较巨大的成熟软件里说,想要直接对技术上进行大的重构 ,基本还是比较困难的,毕竟牵一发而动全身,所涉及到的方方面面都比价多。不可能是一朝一夕就能完成的,是需要在一定的技术能力和时间的支撑下才能完成。相信,以这个团队的能力来说,未来还是很快就能实现的,

人无完人,金无赤足。同理,任何一个软件都会存在一些不可知的BUG,也会出现未知错误,没有办法能根治的。

更多的能考虑到可能发生的问题,提前感知处理,站在用户的角度去实际使用体验软件技术带来的便利性,增加更多人在使用中的体验感。

3 事后的补偿

既然,问题发生了,给用户也带来了困扰,必然会有一些机制或者补偿去让更多是人满足。

语雀团队的处理就是一个字,砸钱,营销到让你满意。针对这次发生的错误直接补偿6个月会员。这可是真不少的,很多C端软件发生错误是没有或者只有很少的补偿的。

可以说,这六个月的会员让大部分人都满意的,不少网友甚至希望每年都来上那么一两次这样的事故,毕竟谁不希望能白白获得福利呢。

还有在另外一个方面来说,这种大方的行为,变相的将事故作为了一个营销点,更多的人了解了语雀,获得的一定的用户增长。

4 关于这个事情的思考

对于普通人来说,这样的事情能带给人们的思考有那么几点:

4.1 一是一定做好本地和云端同步的备份

云端协同,固然是有能很便捷,在任何地方都是能查看处理的。一个很大的弊端是一但这个服务出现问题,损失的不仅仅只是资料,更有可能会耽误很多事情,造成直接或者间接的经济损失。

这时候,多端备份,本地化的重要性就体现出来了,云端出现了问题还有本地的,A机器出了问题,还有B机器的,就是不怕出问题。

4.2 二是出现问题不可怕

确实的,出现了问题,其实不可怕的。只要能积极的面对问题,寻找合适待解决方案去解决问题,并及时告知与之相关的人员,大家心里都有底。

很多时候,可怕的就是出现了问题,隐瞒出题,大家没有了知情权,就蒙在了鼓里。等到有一天,大家就会突然发现原来自己曾经是被欺骗过了,那种感觉会让人很不舒服。

4.3 三是真诚

突然脑子里就想起了这个词,联系语雀这个事情,总的来看,各个方面都还挺真诚的。
从出事情开始,语雀就在微博上更新发现问题,真诚的给大家足够的知情权。

此后也是在一直更新处理的进度,让大众能看到处理的希望。

最后是拿故障公告,不仅写出了事情的原因,详细的解决方案,更是还给了用户福利。这些点就是真诚,很打动人,这在这个社会上算是比较少见的,也是收获了一只好评。

所以真诚就是必杀技!

说了那么多,吃瓜是娱乐,如果能将事情结合自己的工作生活,给自己带来启示和发展,这就是吃瓜的终极奥义吧。

本文作者:redtea 红茶的博客
本文链接:https://redtea.top/
版权声明:本文采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可,非商业转载及引用请注明出处(作者、原文链接),商业转载请联系作者获得授权。

2023/11/12 posted in  杂谈