当一个新盘挂载的 linux 上，可以通过 fdisk -l 指令，查看挂载的磁盘信息，此时虽然已经挂载到主机上，但是主机还不能正常使用。 要想使用新磁盘，需要经过如下几步： 磁盘分区 磁盘格式化 挂载分区到某个目录 经过上面三部后，就可以使用上新的磁盘了，接下来讲解每一步具体应该如何操作 磁盘分区 $ fdisk -l #查看主机所有的磁盘列表 如上图可以看出 /dev/vda 是新的磁盘并且没有进行分区操作，接下来对 /dev/vda 磁盘进行分区操作 $ fdisk /dev/vda // 进入分区操作，这里要填写你的新磁盘信息，不一定和示例一致 $ m //查看帮助 上图为分区对应的各个操作 $ p #输入 p 查看分区列表 目前并没有划分分区，接下来进行第一个分区的划分 $ n #输入 n 划分分区 $ p # 输入 P 划分为主要分区 接下来需要填写编号（1-4之间）和 磁盘的开始扇区和结束山区 这里由于磁盘不大就没有进行过于细的划分，将所有磁盘容量全部划分到主分区1中 $ w # 输入 w 保存 到此磁盘的划分就已经全部完成，再次输入 fdisk -l 可以看到新划分的主分区 /dev/vda1 格式化磁盘 磁盘划分好后，继续要格式分区，这里使用 ext4 进行格式化 $ mkfs.ext4 /dev/vda1 # 用 ext4 扩展文件系统进行格式化 输入完上述命令后，就可以完成格式化了，如果有报错，请参考常见问题章节解决。...

所谓"公钥登录"，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。 要实现公钥登陆的前提是需要用户端需要先生成公/私钥对，正常情况下都是有的，目录为：用户目录下的 .ssh 文件夹，私钥没有后缀，公钥后缀为 .pub。 如果没有公私密钥的话可以使用 ssh-keygen 进行生成. 复制代码 ssh-keygen -f test // -f 制定公司钥名称，回车进入下一步 Enter passphrase (empty for no passphrase): // 这里是密钥口令，如果担心私钥安全可以设置一下 Enter same passphrase again: // 确认密钥口令，回车后完成生成 服务器导入公钥 命令行导入 3ssh-copy-id -i ~/.ssh/test.pub user@host 手动导入 通过账号密码登陆服务器，将公钥复制到 ~/.ssh 目录下,执行下方命令: cat RemotePPK.pub >> authorized_keys xshell 使用公钥登陆演示 输入用户名 选择公钥登陆 导入密钥 选择导入好的密钥点 Ok 点击OK 完成登陆

点进来看的小伙伴是否也想寻求管理中的银弹，期待能学到一招独门绝技，从此独步江湖。 实际上管理与开发一样的，也是不存在银弹的，管理是一个系统性问题，任何的系统性问题都不可能通过引入一个概念或一个制度来解决问题。 那管理还有办法能精进吗？那肯定还是有的，既然是要解决系统性问题，那就需要一个系统的制度去解决问题。 建立共识，打破信息壁垒 建立共识的极致就是将一个团队打造成一个具象的人，整个团队像一个人一样思考。 团队协作中，最大的成本就是沟通成本。每增加一个人，都会增加一份沟通成本。当整个团队像一个人的时候，也就意味着沟通成本趋近于 0 。 就像你左手递过一只笔，右手很自然的接过笔，整个过程不需要进行任何的沟通与思考。上面的例子是有些极限的，但是可以用这个衡量标准作为不断优化团队共识的目标。 制定规范 当团队有了共同的想法和相同的目标，我们还需要制定相应的规范。 拿行军打仗作比喻，共识当然就是打胜仗，规范则是为了打胜仗而锻炼出的战术配合与作战计划。 制定规范的目的就是为了让团队成员做出的成果能够保持在一定的水平，不会因为个体能力的差异而导致做出的成果参差不齐。 当制定了规范后，从外部看整个团队就会觉得团队是一个整体，有组织有纪律，而不是散兵游勇，毫无章法。 建立流程 在团队协作过程中，两个环节对接时经常会产生各种各样的问题，为了解决对接中存在的问题，不得不花费大量的时间进行沟通和调整，才能使工作顺利的推进下去。 建立流程就是为了解决这类问题，为每个工作交接的环节制定相应的标准，对接双方都按照标准进行准备，这样在对接的过程中会减少很多因流程缺失带来的沟通和重复劳动成本的增加。 提升团队凝聚力 在数学概念中 1 +1 =2 是我们在基础数学中就明白的等式，但是在团队协作中却未必成立，有的时候会出现 1 +1 < 2 和 1 + 1 > 2 的效果。 我们在团队协作中是追求 1 + 1 > 2 的效果的，最差我们也想要得到 1 + 1 =2 的结果，最不想的就是 1 + 1 < 2 的情况，如何做到呢？ 秘诀在于提升团队凝聚力，将团队的力量集中起来，利出于一孔，在需要释放的地方集中释放。 Summary 团队管理除了上面说的几个环节还会涉及到其他很多方面。这里只是抛砖引玉，更多的需要我们在不断的探索中总结和提炼。 做事情应该先从思想层面去解决问题，然后用思想去指导行动，通过行动解决遇到的种种问题。很多时候思想的高度直接决定你处理问题的能力大小。每种思想都有它的上限和下限，同一水平思想下，难以拉出数量级上的差距。只有将思想进行提升，才有可能迸发出越级输出的能力。 管理是一个求道的过程，初入管理的时候经常痴迷于追求术，想知道究竟有什么具体的招法来帮助自己度过初入管理的困境，而结果却是：有多努力就有多绝望。当有了管理是求道的认识后，便觉豁然开朗，从困境中解脱出来，从而触碰到管理的门径。 有句话想与君共勉：有道无术，术尚可求也，有术无道，止于术。愿你我一样，能早日找到自己的管理之道。

日常开发中经常会遇到单例模式的使用场景，单例模式可以保证我们初始化出来的结构体只有一个，在一些请求上下文，mysql 连接池..场景经常有着不可估量的作用。 在 golang 开发中，我们应当如何去设计单例模式呢？ 常见的错误书写方式 相信如果你对 PHP 写的比较多的情况下经常会写出下面代码一样的单例模式 package main type Singleton struct { } var ins *Singleton func GetIns() *Singleton { if ins == nil { ins = &Singleton{} } return ins } 那上述代码，在正常开发存在什么样的问题呢？上述代码如果用于 PHP 项目是没有任何问题的，因为 PHP 本事是请求隔离的，因而也不会存在并发的问题，但是如果放在常驻内存类型的语言中就会出现并发性不安全问题。 接下来考虑一个场景，在高并发场景下，同时又两个业务都执行到 ins == nil 而此时的 ins 确实没有实例化，那程序将会如何执行呢？答案显而易见，两个业务都会实例化出自己的 ins 结构体，这显然不符合我们的程序预期。 如何解决 golang 标准库sync中找到了Once类型。它能保证某个操作仅且只执行一次。有了他我们就可以很方便的解决并发的问题了接下看看代码示例： package main import "sync" type Singleton struct { } var ins *Singleton var once sync.Once func GetIns() *Singleton { once....

最近开发中，将一个 php 算法，移植到 golang 中，发现 base64 算法生成的字符串不一致，经过排查发现是由于 ASCII 控制字符导致的原因，加下来看代码 <?php $asciiArr =[10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151]; $str = ''; foreach ($asciiArr as $ascii) { $str .= chr($ascii); } echo base64_encode($str); 上述代码输出： CrvZDM+3uOe4lXaX package main import ( "encoding/base64" "fmt" ) func main() { res := []int{10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151} var str string var b []byte for _, v := range res { str += string(v) b = append(b, byte(v)) } byteCode := base64....