Открытие-2023. Почему стоит стремиться в бигтех

Различие между обычной технологической компанией и большой технологической компанией кроется, как правило, в объёмах разработки. Компания, которая в названии юрлица имеет tech и имеет аккредитацию Минцифры, запросто может разрабатывать не слишком высоконагруженное приложение, мобильную версию, а также внутренние системы ИТ-предприятия, то есть интерпрайзные штуки для всяких учётов-переучётов, вплоть до личных кабинетов сотрудников, где они себе смотрят зарплату.

Большие же компании имеют с десяток основных продуктов (ещё называют вертикалями), которые для пользователя могут быть прозрачно объединены в суперапп. Продукты обычно делятся на менее крупные куски. В целом, это порождает наличие десятков команд разработки.

В плане опс-штук отсюда вытекает огромный объём работ по сборке, деплою и мониторингу всего этого добра. Рано или поздно компания доходит до мысли, что подход "по девопсу на команду" не скейлится, неэффективен и всё такое прочее. Компания создаёт технологическую платформу. Всё это описано в книге Platform Engineering и без меня.

Степень технологической зрелости компании при этом влияет на качество такой платформы. Множество компаний зависают на этапе, когда команда есть, платформа есть, а пользоваться ей сложно. Некоторые команды и вообще не пользуются.

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

Когда в этот зоопарк приходит какая-то задача, опирающаяся на предположение о том, что у всех всё унифицировано - например, закрыть некую уязвимость - то начинается клоунада, приводящая к тому, что меры секьюрити закрываются кое-как.

Этого можно было бы избежать, если проектировать сразу хорошо. Увы, для этого нужен скилл. Разработчики на определённом этапе изучают принципы (паттерны) предметного проектирования. Как правило, не зная паттернов, нереально писать поддерживаемый код. Проектирование инфраструктуры отличается хотя бы тем, что его принципы многие знают лишь поверхностно. Можно работать SRE, не читав гуглокниги про SRE. Инфраструктурный код при этом - лишь обёртка для конфигов, притом не слишком функциональная.

Особенность бигтеха зачастую состоит в том, что туда трудно наняться. Миллион собеседований, секции по алгоритмам для девопсов, системный дезайн, калча фит интервью, вот это всё. Это делается для того, чтобы выловить с рынка настоящих энтузиастов. Да, можно насобачиться проходить эти интервью, но на той стороне ждут не натасканных чуваков, а тех, кто в своё удовольствие учил проганье, работая сисадмином.

У энтузиастов больше способностей, чем у рабочих лошадок, которые просто выучили скилл и просто им зарабатывают. Но этого мало - бигтехи поддерживают энтузиазм. Это может выражаться, в частности, в доверии командам, в том, что им не зарубают "украшательства" и "свистоперделки", сделанные с прицелом на будущее.

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

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

где-то - завышенные требования по производительности инженеров,
где-то - тупая система пересмотра зарплат,
где-то - палки в колёса со стороны регуляторов,
где-то - шизоатмосфера, идиотская корпоративщина.

Чисто практический выхлоп может быть в том, что поработав в бигтехе, вы не будете бояться увольнений от слова "совсем". Кроме того, нетворкинг поможет вам устроиться на контракт, если вас задолбает необходимость работать всегда, кроме отпуска.