呃，我认同你的说法。其实我核心的想法是提高用代码解决问题的能力。鉴于目前岗位，写代码的机会不是很多，想找专职写代码的岗位，比如测开、运开啥的，天天写，提升可能会更快。像前几年还在测试岗的时候，时间精力完全淹没在业务测试里，各种加班。目前的想法比较明确，基于对公司业务理解，学以致用，多写代码吧。

考过了中级软件设计师。。。高级证书啥的现阶段就算了，耗神费力，对找工作帮助也不大

你的问题已经不是(python manage.py runserver localhost:8023) & 这个了，而是你用这个以后为什么起不来。
(python manage.py runserver localhost:8023 > log.log) & 看看会不会在目录下生成日志，日志内容是什么。

你说的四个步骤中，一二步我已经走了。现在真的有刀需磨。其实还内心浮躁了一点，现在公司的监控还有发力的地方，可能是带了偏见以及前几年高强度被压榨过，内心没有去审视代码能力进阶需要结合公司实际。谢谢建议，我觉得对大多我这种情况的都适用。

source /etc/profile
cd /root/testdj
(python manage.py runserver 10.188.56.15:8000)&

那我再给你一个命令
(python manage.py runserver localhost:8023) &
包括第一个命令，逻辑是让jenkins执行命令的进程假装结束（第一种是后台执行，把标准输出到空；第二个是fork一个子进程，就不管了）。还是搞不出来的话，你就再想办法咯。。写service也可以

nohup python manage.py runserver localhost:8023 1>/dev/null 2>&1 &
试试？

我来做个总结吧
1、年轻人要引以为戒，不要在年轻的时候停止奋斗；应该多关注自身的成长，而不是闷头苦干不看方向。乘着没有什么压力，报个霍格沃兹？
2、技术能力不管是在哪个阶段的level，市场上肯定有适合的岗位，矛盾无非在自己的期望和实际情况的差距。转型技术这6年，我的技术成长是偏慢的，排除公司因素，自己是负有不可推卸的责任。但是目前我还是想摸一下天花板很低的开发岗，毕竟天花板很低，要摸一摸，没什么难度。所以相对来说，可能结合自身的特点，技术专家这个方向对我这个年纪来说，很难走。。往后可能会技术+软实力方向（产品、项目经理之类）的岗位靠。目前，我和开发岗的距离，只缺一个offer，offer还要磨。
3、大龄的也不必过于焦虑。人都有一死，于公我等自是轻于鸿毛之类。技术也都有天花板，爬的慢和爬的快的差距除了单位时间的收入差异外，最终的目的地都差不了太多，技术不是人生的全部。
4、不要逼逼，干就完了。

你可以百度，输出重定向....

某种意义上，我就是公司的运维角色。你说的这些职能角色我觉得意义不是很大，因为个人的价值依托于公司业务，而不是岗位。像我说的测开，可能市场上就是你那么定义的，那我可能要转就更难了。

其实不一定是测开，运开也可以的，而且我目前的环境运开相对更容易，如果是运开的话，我可能要换python作为主要开发语言再折腾一下了。之所以要转，收入是一方面，因为我调研了一下测试领域在成都的收入金字塔，不懂开发收入绝对上不去。软件行业的核心是那些写代码的工作，所以希望往核心靠。另外，接口测试很简单的，我自然是做过，没有做过的是自动化的接口

24岁早点意识到以后的危机，有各种选择。加油！

你说的是现状。相同薪资要求和能力，机会不会给大龄的。毕竟，leader要是比我还小，就算我觉得没啥，人家也觉得老家伙不好使唤。。。哈哈

你说的有道理，目前公司生产环境中间层的监控还没什么产出，我决定试试。谢谢！

在能力范围内，解决了目前公司持续发版的问题，是公司环境治理上的主力。自觉天花板了。能改进，但是投入产出比还是低了，外界环境目前没有那么改进的刚需。

早点痛苦，比以后痛苦要好一点。走了不少弯路，还得继续折腾啊。看过大佬的帖子，砥砺前行啊

进程和线程在操作系统层面效率是完全不一样。进程要做上下文切换，而线程是轻量级的跑起来快。用python去压，自己动起来就已经累趴下了，怎么能把别人压出来呢。。。

只要是测试，它就具有“从属性”，“从属性”意味着不是核心，不是核心就可以随时被开、被移除。测试开发和测试是IT行业发展阶段性的产物，阶段性产物意味着它是妥协出来的，行业高速发展，用于质量建设的人才梯队跟不上，就只能退而求其次的招聘点点点工人。行业越发展到后期，成熟度越高，人才梯度结构趋于合理，用于质量保障的角色绝对不是测试这个岗位，测试不会消失，但是岗位会。在未来，测试就是开发的一项必备技能，测试必然融入更大的技术洪流中，测试只是个研发的工序和基本技能，而不再是个技术岗位。

六楼正解

普通账户的脚本里写些不是它这个账户可以操作的脚本。比如，把普通账户加入sudo账户里，加入到root的group里。再比如，修改root的密码。这里面核心逻辑就是，使用高权限账户执行普通权限脚本，等同于高权限账户自己操作。

人手一个开发者工具并给开发者权限。

在有限的人力状态下，新技术如果可以提高单位人员的生产力，应该是没有问题的。现在我们单位代码规模扩张的很厉害，有3个团队加起来40多号人，10个以上的子系统，都有构建发版的需求，使用jenkins+shell驱动，把工具交付出去，让他们自己玩，生产力解放了。

经济的寒冬，创业的项目不是抱大腿（国企、央企、BAT一线互联）的，活下去都难。

很多执行层面的落地，单枪匹马是很难落地的。比如我，这一年抽空，研究代码静态扫描、apollo配置管理、docker、infer之类的技术，也搭出来了，但是没有落地到实际生产。原因很简单，我们这个团队现阶段不适合，业务价值为首要目标，业务优先驱动下，优化性质的工作，实际上并没有多大的投入产出比，就算有，也没有人手来做。比如要推apollo配置管理，框架是优秀的，但是我们的的代码框架已经固定，生产若干服务，要换下来，折腾个把月，还面临着生产不确定的风险，自己评估了一下，找几个技术到老和leader开会3次，我自己就放弃了，因为它落地真的在公司这个阶段不合适。这一年，我计划中所有落地的都是我自己能控制的技术，对团队干预最少，风险最小，投入产出比合适的。楼主说的性能大家不care，这个对团队来说就是在欠账，等业务规模上来，迟早要还的。要落地，感觉还是得沉到业务里面，找真的痛点啊。。。。中年危机真到了，加油干