2017年，除工作之外的时间估计更多的都花费在跑步上了。从4月15日的TNF50，到7月14日的崇礼越野50，再到9月10的太原国际马拉松和9月17日的北京国际马拉松，以及11月4号陪我宇神奥森100的最后30公里。当然，跑量不算多，但是和忙碌的工作穿插起来，也构成了2017完美的一年，这一年以跑步开始以跑步结束，收获乐趣的同时也让我成长了更多。2017，首先感谢我的家人朋友，我的京东跑友以及我的同事领导们，最后也要感谢在你们指导下的我自己，是你们的指导、包容和支持，让我在这一年里收获良多。
2018-run.jpeg
2018.png
2018年，我的个人活动中心依旧会是跑步，但是我想尝试更多，挑战不同难度的越野比赛，以此来不断磨练自己的心性；同时我会拼劲全力来做好与自己本职工作相关的工作，结合场景为团队创造价值，为什么是拼劲全力呢？因为在我眼里，工作对于我来说远远不是最终要的，生活才是，所以我不会以身试险，经常去拿自己的身体换取工作的回报，当然偶尔的几次还是可以的，毕竟我爱我做的工作。所以最后，我会将跑步和工作之外的时间都投入到家庭和生活之中(好像也没有太多时间了哦)。
回顾2017
马拉松的回顾之前已经总结了，2017年在工作以及个人职业生涯规划上的时间投入是比较多的，所以好像除了工作以及职业生涯方面的回顾和思考好像也么有什么了。
专注
2017年上半年，在外面参加的技术大会会比较多，一方面是因为想接触一些技术界的大神老师们，另外一方面也是想学习学习，学习一些企业IT架构以及对于某种业务场景下，某种技术组合的解决方案最终产生的价值效益比。
虽然过去的一年在企业容器化道路上没有一些非常成功的案例实践，但是在过程中自己也摸索出一些通用的门道，包括一些业务场景的技术选型，业务价值的交付链以及用户友好性的考虑，同时在对待项目过程中的及时反馈和向上管理等多方面的问题。但是说这么多，你可能会觉得很虚，其实真的很虚，以上涉及到的业务场景、价值交付、用户以及项目管理中的一些东西，说起来其实很简单，但是实际做起来有多难想必只有亲身经历过的人才知道，因为整个项目过程中可能涉及的是一个小生态，而不仅仅是项目那么简单。
2017年，我面过几个人，也被几个人面过，面完之后也的确给我的感觉是很虚。可能也是得益于当前各种技术发展的太快并且各种对应的开源软件层出不穷吧，大家普遍的感觉就是，只要这个东西还不错，能解决一些问题，然后就拿来就用，至于这个东西底层是怎么实现的，如何去进行优化并结合其他周边的业务场景，考虑这个的人并不是很多，所以最后造成的结果就是，维护一些项目可能需要各种各样的工具，最终被很多东西裹挟(其实这也就解释了为什么很多大厂都是基于某个技术进行开发适合自己的产品了)。当然说这么多，我想表达的只是：
2018年，我会更加专注于去做某一件事，更加深入的去研究某一个技术以及最基础的知识，如果你还没有这样做，我建议一定要腾出来时间去专注于某一件事的研究，我相信那样会有惊喜发生。
记录
17年，同样有一件事情没有做好，那就是写作(暂且叫做写作吧)和分享，最早维护了一个微信公众号逼格运维说，主要用来分享我个人经历思考以及运维方面的知识，后来由于个人经历方面的原因，将运维方面的知识迁移到简书BG运维上，来分享运维相关的技术文章，而后个人微信公众号就没再分享过了，一方面因为微信公众号内容的排版问题，另外一方面感觉实在没有去深入思考某些相关的东西。到后来，索性自己维护一个个人主页xxbandy.github.io,基于Markdown的语法,排版方便也能进行历史文章的修改，因此就将当初想在公众号逼格运维说做的事情慢慢迁移到个人主页(xxbandy.github.io)了。这里可以向大家推荐几个Markdown编辑器，免费的可以选择有道云笔记，付费用户可以选择为知笔记，还有一款免费的Markdown语法PPT编辑器Marp，经过多次尝试使用，个人感觉上述三个软件还是不错的。
那我为什么要做这件事呢？一方面是想通过文字的方式记录自己的实践和思考，未来回过头来有反思和优化依据;另外一方面是想培养自己书写总结的能力。而后来我发现通过这种写作的方式很能提高工作中的沟通效率，在工作中做到事必有果，文档记录是一个最简单且高效的方式了。
所以，2018年，我会尽量将自己的工作以及项目结论进行文档化记录一方面巩固自己，另外一方面提高团队整体协作效率
适合
老哥以前经常给我说一句话"适合自己的才是最好的"，我觉得这句话放在那里都是最合适不过的。而像我们搞运维的也一样，如何站在业务方的角度去考虑问题，如何去深挖当前业务痛点并结合特定技术来提供解决方案，这些对于最终结果的好坏都是致命的因素。举个很简单的例子，如果按照容器以及周边生态本身的技术特性去推动企业应用容器化改造，这样的效果肯定是大打折扣的，因为不论是按照容器化或者微服务化的思想，传统的业务架构都是存在一定差异性的，只从技术的角度去推动，那么不仅在时间上不乐观，而且很有可能因为某一次失误失去所有机会。只有根据当前业务场景以及实际痛点去调整改造技术方案，才有可能最大程度的推进容器化项目改造。我承认，我不是一个忠实的技术拥护者，因为我认为如果某个技术不能找到合适的场景，那么该技术本身是没有价值的，而映射到企业内部，如果你做出来一款没有合适场景的软件系统，不仅仅该产品没有价值，当没有人使用它的时候，想必开发者本身也有点灰心了吧，至少我有过这种感觉。
那，很明显了，2018年做项目和产品，我可能不会贸然行动了，至少要搞清楚业务的场景以及痛点是什么，也就是不要着急去做技术架构，可以先去了解业务和产品架构，而后再规划技术产品。一定要结合场景去做产品，因为适合业务场景的才是最好的产品。
2017年，个人感觉工作上除了经历比较多，犯错比较多之外，好像没有什么做的比较成功的地方，但本身这种经历对于我而言已经是莫大的财富了，这也要感谢我领导超哥的支持，以及团队其他小伙伴们的包容和理解了。
展望2018
8.png
突然很喜欢8这个数字，不仅仅是它有"fa"的谐音，也不仅仅是因为昨天跑"2018"只剩下"8"的图案，而是因为对"8"有了另外一种解读---"双循环结构"，不断更新迭代的循环系统会让系统本身更加健壮有力。
2018，专注于自己想做的并结合实际的业务场景踏实去做，且要不断积累自己的各方面能力。金融领域的运维并不只是有"稳定，效率，成本","质量和安全"，所以专注于某一个点精耕细作，结合金融领域的运维继续努力去做事。
对了，得什么不要得病，2018，身体健康很重要。祝大家在新的一年里身体健康，888！
网友评论