В мои ранние дни Linux более 20 лет назад все, что вам нужно было сделать, это настроить что-то в файлах конфигурации. И у меня все работало нормально.

В какой-то момент появилось нечто, называемое «виртуализацией». После этого все больше и больше систем устанавливалось за все меньшее и еще меньшее время. Проблема заключалась в том, чтобы синхронизировать все конфигурации, времени всегда было меньше, и, как всегда, команда была недоукомплектована. Конечно, вы могли копировать конфиги или делиться ими тем или иным способом, но меня это не очень устраивало. Поэтому я начал думать о том, чтобы написать какое-то решение для этого, но быстро отказался от этого. В тот момент барьер казался мне слишком высоким. И в целом я системный администратор, а не разработчик программного обеспечения, если бы я хотел быть разработчиком, я им стал. ;-)

Но это длилось недолго, и следующим важным событием для меня стало управление конфигурацией через puppet около 8 или 9 лет назад. Puppet был и остается таким замечательным инструментом, который решает множество проблем в современном мире системных администраторов. Но как всегда новые вещи приходят с новыми проблемами. Так что мне пришлось писать код чуть ли не в первый раз после моего технического образования. Хорошо, я должен признать, что это было связано с кукольным SDL на очень высоком уровне и более описательным способом, но это был совершенно новый способ. Вам нужно было подумать о том, как работать над puppet с разными людьми и командами, как вы организуете структуру кода, где и как вы сохраняете и делитесь им, как насчет версий, качества кода и всего того, что приходит вместе с новым подходом. .

Вскоре после этого у меня появилась возможность перейти на руководящую роль, отвечающую за ИТ-инфраструктуру страховой компании, на что я согласился. Так что техническая часть с годами все больше и больше отходила на задний план, а люди и управление проектами выходили на передний план. Мы экспериментировали со скрамом и канбаном, чтобы решить обе проблемы одновременно. И это работало очень хорошо в вашей команде, но боролось на границе с другими командами. Поскольку компания была очень консервативной и медленной, этот барьер не мог быть преодолен.

Поэтому я пошел дальше и начал работать системным архитектором в крупной отраслевой компании. Со всеми моими знаниями в области технологий и я пришел как раз вовремя, так как моя новая компания находится в тяжелом процессе цифровой трансформации и движется очень быстро и гибко в этом новом направлении. Моя миссия — автоматизировать все установки и настройки Linux в локальном облаке, а также в общедоступных облаках, таких как AWS и Azure. Излишне говорить, что все машины должны соответствовать требованиям безопасности и правилам компании. Здесь задействовано действительно много разных API, производителей и языков программирования. В моей команде разработчики программного обеспечения и системные администраторы работают очень тесно. Многие задачи по кодированию выполняются только разработчиками программного обеспечения, но они в значительной степени зависят от системных администраторов, как и от разработчиков. Причина в том, что у разработчиков гораздо меньше знаний о поведении инфраструктуры, а администраторы часто еще не могут кодировать на таком глубоком уровне.

Прошло еще почти 10 лет с тех пор, как появились первые потребности в программировании для системных администраторов, и, как показывает история, уметь программировать становится все более и более важным. На мой взгляд, это почти на грани того, чтобы быть слишком поздно. Если вы не сможете программировать в будущем, вы больше не сможете выполнять свою работу. Так что я могу только посоветовать вам научиться программировать и побыстрее!

Что можно сделать для начала?

У вас есть подобный опыт или вы хотите рассказать, как вы начали программировать, просто расскажите в комментариях!

*это партнерская ссылка