电脑的linux系统主机名字为啥会变来变去

Posted 2023-05-13

参考技术A 下面是在Linux系统下查看及修改系统名称的方法及步骤：
1、查看系统的系统名称：
使用root用户登录，在终端控制台输入：
hostname
[root@linux
]#
hostname
2、临时修改系统名称：
[root@linux
]#
hostname
yourname
注：不过第2步的修改只能临时有效，机器重启又还原了，想要让修改永久生效，还要继续下面的步骤：
3、修改hosts
文件（路径：/etc/hosts）：
[root@linux
]#
vi
/etc/hosts
把hosts里面所有原来的名称改成你想改成的名称，此外，还需要特别注意的是，hosts文件里面的ip必须改成系统现在拥有的ip（ip查询方式：#
ifconfig）
4、修改host文件（路径：/etc/hostname）：
[root@linux
]#
vi
/etc/hostname
5、重启机器：
[root@linux
]#
reboot

关于最近的一些事情

　　说说最近遇到的事情，有些思考还不够全面，先做个记录。

第一件事情关于产品交付

　　大致经过是这样：

　　我们开发了一款产品，但是这款产品具备一定的定制性，关于定制，有对应的流程说明，首先是售前牵头，和销售配合着与客户沟通定制内容，然后与研发确认，然后再与客户沟通并确认。有一个项目，可能也是市场的特殊情况，前后2周以内需求变化了至少5次，里面都涉及各种大大小小的内容，而且有些内容反复变来变去。硬件产品的需求变化，研发需要支出很多精力不断调整产品来响应相关的变化。因为售前、销售基本对产品细节（定制涉及的内容）不够了解，或关注度较低，导致他们只充当了信息直接传递的角色，真正的售前工作转嫁给了研发，这也为后续的问题埋下了伏笔。

　　最终这个订单敲定之后，要求10天之内交货，生产（包含采购）直接就不干了。这本来是市场部临时组合的一个产品类型，研发收到的指令在前期包含了很多不确定性，按流程，研发只需要把产品对应的生产归档文件给到生产，由生产来进行物料采购和生产装配工作。生产可能由于人手不足或其他原因（能力问题？），效率极低，直接回复销售，“无法发货”。但销售强行要求“必须发货”。这时候就把研发也搭进来了。研发就充当起了采购的角色，开始进行物料购买，并不断核对交期，就怕哪颗物料延期，导致整个产品无法按时交货。

　　好不容易物料都齐了，送出去加工，回来，生产人力也不够，研发必须安排人下来做生产。噼里啪啦都安装好了，终于赶在约定的交货期可以发货了。产品经理跑下来看了，然后直接说你们这样不能发货。这这这，都有问题，要重新返工。但是哪有返工的时间呢。产品经理直接要求生产返工，生产直接反呛说研发当时就没要求。研发夹在中间好苦，这个样机前面就得到过产品经理的确认。现在又变了，说这是基本问题，没想到我们生产的工艺水平这么差。

　　货到了现场，新问题出现了。尺寸上出现了偏差，导致产品无法完成安装。研发远程协助，帮客户定位了问题，是客户现成的一个支架尺寸偏差太大，与前期“定制沟通”过程所描述的内容不符。研发本着帮忙的态度，给客户想了很多解决方案。但最后销售不乐意了，直接就和客户一伙，说是研发的设计问题，说客户根本不承认我们所谓的沟通描述。直接要求公司安排人去现场处理。研发又苦逼的开始做售后工作。一来售后说，这是新产品，我们还不会；二来销售说，这就是你研发的责任。研发心里苦啊。只能出差去兜底。而且去了，只能给客户当孙子，把很多本应客户做的事情，都揽到自己身上做了。毕竟销售已经不在己方阵营了。

=======================================================================

　　前前后后，研发除了本职工作，还做了售前、采购、生产、售后的工作，研发成了万金油，但这里面的风险是，行政命令安排下来，研发必须要顶上，必须要兜底，而且可能最终还得为这个所谓的“质量事故”背锅。

　　可研发人员是否具备做这些工作的能力，是否适合去做这些工作？

　　又或者研发人员是否本来就应该具备做这些工作的能力？或至少能够识别其中的风险呢？

　　是否应该以所谓的“全栈”来对研发人员做要求？

　　或者我们应该设计一套适当健全的机制，来对上述提到的一些风险进行提前的规避。例如尽早识别所有的干系人，以及干系人必须参与的过程。（可真正火烧眉毛的时候，有时候流程或许就直接被跳过了。）

　　再或者我们应该怎样训练一个团队，来打这样的硬仗，团队成员需要具备哪些能力和素养。

　　我觉得还是很值得思考。事情虽然目前已经按文中描述执行了，但是研发人员如果经常性的被要求完成这些研发以外的工作，可能研发的本职工作就会打折扣。当然如果从另外一个角度来看这个事情，研发在参与这些事情的过程中，可以体会到一个产品的生产交付运维的全过程，有利于他们对产品有更全面的了解？于是他们就能研发出更适合这个流程的产品了？这个说法成立吗？

 

第二件事情是关于版本管理（其实背后应该是对人的管理）

　　版本管理算是研发管理里面一个重要环节。我约束了产品对外的唯一版本号，但产品的范围包含了硬件、嵌入式软件，嵌入式软件部分又包含了固件和应用。

　　所以我定义：
　　1、但凡产品的范围内的任一部分发生变更，都必须更新产品的版本号

　　2、又为了让产品版本号简单好查，于是将嵌入式软件应用部分的版本号与产品的版本号保持一致。（大部分更新都来自于“嵌入式应用”）

　　这样在平时大部分场景是OK的，但是遇到特殊场景，比如更改了硬件，或者更改了嵌入式软件固件部分，本来不需要更新嵌入式软件的应用部分，但为了确保产品版本号与之一致，又必须把嵌入式应用也更新一把（实际内容没变，仅变化版本号）。很多人就不理解，最近一个项目小组的组长也犯错，这个版本号的问题，已经跟所有人普及了很多次，他还是由着性子，我行我素，我可能说话语气强烈了一点，他就直接甩脸色，版本扔给我就直接下班走人了，喊他也不愿搭理。先不说周末安排他们团队来加班，协助生产处理事情，就这态度，我当时就想立马让他走人。

=======================================================================

　　我反思了一下，可能还是得从领导力、绩效管理的角度出发吧。还是重读《构建之法》第17章，“人，绩效和职业道德”，再来评论。