Человек и машина

Я еще раз скажу, что мне крайне льстит, что количество подписчиков растет, благодаря чему у меня вновь появилась мотивация создавать для вас контент. Поэтому я предлагаю вам сделку.

Все что от вас требуется - расскажите обо мне своим друзьям и коллегам по цеху.
У меня (пока) не стоит планов по монетизации канала. Я парень простой, тихий и не веду канал о лайфхаках или крипте.
Моя выгода - у меня будет больше мотивации писать, писать и писать.
Ваша выгода - больше читателей - больше вопросов и предложений - больше контента.

Спасибо, и давайте оставаться на связи.

После небольшого лирического отступления давайте вернемся к моей истории.

Итак, моя проблема - надо собрать DCOS кластер, а я понятия не имею, что это вообще такое.

Тут я немного похвастаюсь - за весь свой опыт с самых низов я обрел полезный скилл, как я его называю, native engineering.
Под этим скилом я подразумеваю набор определенных навыков, присущих любому ИТшнику, которые объединяются в одно большое “сакральное знание”. Проще говоря, если вы ИМЕЕТЕ ПРЕДСТАВЛЕНИЕ как “все” (сети, компьютеры, Linux, Windows, базы данных, REST, HTTP вызовы, API вызовы, SSL, configuration management, VCS/SCM, CI/CD и многое многое другое) работает - освоить конкретный продукт, каким бы сложным он ни был, вам не составит труда.

Взять тот же AWS - вас абсолютно не должно волновать, каким образом Амазон содержит свои серверы и системы хранения данных. Вы знаете (и Амазон все время это твердит), что все их сервисы являются API based, а значит любое движение внутри является следствием множества систем, работающих между собой. Вы знаете, что EC2 (виртуальные серверы в облаке Амазона) это виртуальные машины, запускаемые внутри VPC, собираемые из образа ОС, к которым привязывается внутренний и/или внешний IP адрес. Как *конкретно* это делается, вас абсолютно не касается.

Вообще я полюбил Амазон как минимум за то, что он отвязал потребность людей залезать системе под капот.

И вот я приступаю к изучению DCOS. Я знаю, что он дает мне возможность запускать внутри него контейнеры, проводить им проверки и перезапускать, когда те отваливаются.
Чтобы пощупать систему, у меня есть два варианта - запустить кластер локально либо в облаке по заранее заготовленному шаблону.

И как раз тут мой внутренний инженер разбушевался, ведь как это так - запускать что-то, не разобравшись?
Здесь и появляется первое разочарование в себе - DCOS на самом деле очень сложный продукт, состоящий из десятков сложных компонентов, этакий Photoshop из мира DevOps. Если совсем немного окунуться в архитектуру, то получается следующее:
- Есть bootstrap сервер, который хранит в себе дистрибутив DCOS c разными настройками для мастера и агентов.
- Есть мастер - “голова”, которая собирает данные по ресурсам от агентов и распределяет между ними приложения через Marathon
- Есть агент - “тело”, на котором установлен mesos агент, который рапортует мастеру о своих доступных ресурсах.

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

Поэтому читателю, попросившему совета о множественных, слишком сложных системах, вот два мои совета:
- Забей болт.
- Отталкивайся от потребностей бизнеса и своих личных.

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

Но что касается тех, кто хочет залезть с головой в продукт Mesosphere, вот мое предложение:
- Поставьте его локально (как, читайте тут - https://github.com/dcos/dcos-vagrant)
- Поставьте его вручную (есть хорошая подробная документация https://docs.mesosphere.com/1.11/installing/oss/custom/advanced/)

Но на этом мое исследование не заканчивается, о продолжении (как я изучаю способы поднимать его быстро и легко с помощью Infrastructure-as-Code) я расскажу уже на следующее неделе.

Так что всем хороших выходных и веселой пятницы!

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

Вчера мы посмотрели прекрасный фильм-расследование про Игоря Сечина, снятый какой-то группой noname’ов. Не буду вдаваться в подробности фильма, политики, коррумпированности и прочего. В фильме была добивающая деталь.

Гендиректор крупнейшей нефтяной компании в России абсолютно бездарно распоряжается деньгами. Покупает огромные участки по бешеной стоимости, возводит там дорогостоящие архитектурные проекты, от несчастной любви их ломает, строит новые. Человек заказал себе в вертолет пледы по 125 тысяч рублей за штуку. Пледы, Карл!

В рамках своей программы “Откажись от 3 вещей, мешающих тебе жить” я отказался от Вконтакте, Инстаграма и привычки осуждать других.
Посему у меня к Сечину и претензий нет. Может человек ворует, решает все вопросы через административный аппарат, его менеджерские компетенции вызывают сомнение. Ну да Бог с ним, крепкого здоровья, удачи и успехов. Пусть у него и его детей все будет хорошо.

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

Сам по себе я хочу следовать “умной” жадности. Если у тебя много денег, вложи их во что-то, чтобы денег стало ЕЩЕ больше.

Но сегодня утром мне пришла в голову интересная мысль. Некоторое время назад я услышал интересную цитату: “Если деньги пришли легко, от них нужно так же легко избавляться.” И вот я думаю - может все эти олигархи, талантливые 21-летние бизнесмены и бизнесвумены и прочая илитка тратит деньги направо и налево просто напросто потому, что они им легко достались, и они всего лишь соблюдают эту традицию?

В Рено члены правления тоже получают довольно астрономические суммы (одни только русские топы имеют зарплату выше полумиллиона рублей в месяц, про топов экспатов вообще молчу). Однако я не могу сказать, что эти люди бесились с жиру и вбухивали деньги в элементы роскоши. Нередко задерживаясь на работе до 8 или 9 часов вечера, я, покидая офис, видел горящие огни в их кабинетах. Бедные менеджеры, походу, вообще не успевали тратить заработанные деньги.

Если мантра “легко получил - легко отдал” имеет место быть, то это объясняет, почему олигархат так бездарно и скучно тратит огромные суммы денег, а наемные C-level менеджеры в коммерческих компаниях ведут себя… скромнее что ли.

А когда появился Докер, проблема зависимостей была решена. Я не буду расписывать, как устроен и работает Докер (для неподготовленного читателя это очень сложно, но если очень хочется - пишите мне в личку, постараюсь расписать). Докер создает определенный слой изоляции, где ваша программа запаковывается в определенный “контейнер”. Внутрь вашего контейнера вы устанавливаете все зависимости, добавляете вашу программу, и - вуаля! - ваша программа “запакована”. Запустить ее можно где угодно, достаточно на сервере установить сам Докер и выкатить туда “образ” вашего контейнера.

Докер вообще ВЗОРВАЛ интернет, это была технологическая революция сродни виртуализации. Но, как у каждой новой технологии, у Докера есть свои проблемы.
Например, если вы “убьете” контейнер, все данные на нем пропадают - соответственно он не подходит под базы данных. Впоследствии эту задачу решили с помощью persistent volumes - когда контейнер использует диск самого сервера.
Или другая проблема - контейнер умирает, и вам нужно, чтобы он поднимался сам автоматически.
Или если у вас несколько контейнеров, на которых ваш сайт - как сбалансированно распределять клиентские запросы между ними (помните, что контейнеры иногда умирают).
Или как обновлять ПО. Чтобы запустить контейнер с “новым” ПО, надо остановить контейнер со “старым” ПО, а значит клиенты некоторое время не смогут работать с сайтом.

Чтобы решить такие проблемы, придумали системы контейнерной оркестрации. Самым популярным сейчас является Kubernetes, который из коробки все это делает.

Но мы ребята особенные и используем DC/OS (который на самом деле не контейнерная оркестрация, а система, объединяющая ресурсы нескольких серверов - процессор, память и диск - в один большой pool). Поскольку DC/OS создает определенный уровень абстракции и управления ресурсами, на него сверху ставится Marathon - как раз та самая система оркестрации, которая получает данные о ресурсах от DC/OS и на основе этих данных решает, где и как запускать контейнеры. На DC/OS так же ставится специальный балансировщик, который будет распределять поток клиентских данных и запросов на нужные контейнеры.

Вот как-то так.

C DC/OS у меня следующие проблемы:
1. Я его вообще не знаю.
2. DC/OS довольно сложный. Документация не в полной мере раскрывает, что под капотом, а инструкция по установке предлагает скачать заранее заготовленный шаблон инфраструктуры, чтобы попробовать его у себя локально или в AWS

Как любой уважающий себя специалист, я должен сначала изучить то, что хочу внедрить, поэтому я провожу определенное “исследование”. О нем я расскажу завтра. На сегодня информации хватит. 😉

Про первый кусок технологий поговорили, теперь о втором - Docker и DC/OS.

Предположим, что вы хотите открыть свой интернет-магазин плюшевых хомячков. Бизнес модель есть, бюджет есть, наемный тыжпрограммист есть.
По “классике”, ваш тыжпрограммист арендует сервер, поставит туда “веб” сервер (система для обслуживания сайтов) и базу данных, чтобы хранить информацию о клиентах и товарах. Здесь надо понимать, что каждая система (веб-сервер, СУБД и тд) это программы. Каждая программа состоит из “своего” программного кода и зависимостей.

Например, для того, чтобы поставить Nginx, на вашем сервере должен стоять GCC (GNU C Сompiler), а для GCC требуется сам C.
Вы поставили СУБД и веб-сервер, написали ваш сайт “ООО Плюшевые хомячки”. Сайт запущен, клиент радостно заходит на него и заказывает себе игрушки. Здорово, правда?

В какой-то момент к вам начинает приходить больше посетителей, и сервер начинает не выдерживать нагрузки (помните, что у вас на 1 сервере и веб сайт, и база данных). Что делать? Заказывать новый сервер и ставить туда ваш вебсайт. А потом еще. И еще. И еще…
Учитывая, что программист все ставит руками, “дублирование” статического сайта начинает занимать больше времени, чем разработка. Это первая проблема.

А потом вы хотите сделать модную систему анализа пользовательского поведения, чтобы определить свою ЦА и начать активно раскручиваться. Для этого нужно опять заказывать сервер, писать под него ПО с кучей зависимостей, а ваша маленькая база и так еле справляется, вы заказываете еще сервер под дублирование БД, настраиваете кластеризацию, ставите перед ними балансировщик, затем дублируете систему анализа данных…

А затем вы разрабатываете “свою” систему email маркетинга, чтобы привлечь еще больше клиентов, ваше приложение становится сложным, и для отказоустойчивости вы применяете очередь сообщений (ЕЩЕ 1 сервер, еще больше ручной работы)…

Уловили идею?

До того как появился Докер, эти проблемы решались такими прикольными способами как управление конфигурациями, автоматизация управления и Infrastructure-as-Code. Идея заключается в том, что в определенных файлах вы описываете, что и как должно быть установлено и где - а затем говорите системе установить это ПО на сервер-1, вот это ПО на сервер-2, а на сервер-3 поменять адрес веб сайта с fluffyhamster.ru на hamsterforlove.ru.
Применение такого подхода сокращает время на настройку и развертывание, но не решает проблему зависимостей - так что поговорим и о ней.

Есть такой прекрасный язык программирования как Python. Я этот язык ну очень сильно люблю и когда программирую, то на нем и только на нем.
У Питона есть две “мастер” версии - 2 и 3. Они друг от друга сильно отличаются, и программа, написанная на Питон 2, вряд ли заработает на Питон 3. Разработчики обычно пишут программы, совместимые с обеими версиями, а умные разработчики переписывают старые программы под Питон 3.

Итак, вот ваш кейс. В вашем онлайн-магазине есть две маленькие программы - одна генерирует электронную рассылку для клиентов, а вторая анализирует пользователей в БД, чтобы выявить интересные для них предложения. Исторически так сложилось, что первая программа была написана на Питон 2, а вторая на Питон 3. Поскольку программы маленькие, заказывать под них отдельный сервер непозволительная роскошь (в простонародье ДОРОГО). Держать их на одном сервере - геморрой с точки зрения “объяснить программе 1 использовать вот этот вот Питон, а программе 2 вот это вот Питон, и НЕ НАОБОРОТ, ТЫ ЧТО НАДЕЛАЛ, У НАС СЕЙЧАС КЛИЕНТЫ ВЗБЕСЯТСЯ, ВЕРНИ КАК БЫЛО, ЧТО ЗНАЧИТ ТЫ УДАЛИЛ 3 ПИТОН, ТЫ НАРКОМАН ЧТОЛИ?”

Вот под это вот все мне и нужно собрать свой кластер. Кластер должен быть производительным, расширяемым и отказоустойчивым (собственно самые базовые требования для инженера или архитектора).

Опытный человек уже понял мою проблему - создать новую подсеть с привязкой к другой AZ я уже не могу, поскольку уже существующая большая подсеть забрала остатки IP адресов из всего VPC. А если соберу кластер в текущей подсети, то становлюсь зависим от одного AZ.

Поэтому варианта у меня два:
- YOLO. Поставить все как есть на текущие подсети и молиться, чтобы не отвалилось.
- Создать новый VPC в том же регионе и наладить коммуникацию с текущим VPC.

Я еще не определился с выбором, но вот первая проблема - отказоустойчивость. Давайте ее запомним.

Для начала небольшой ликбез, о том как вообще устроено у нас все и как работает. Для моих читателей, не работающих в ИТ, постараюсь максимально подробно и просто описать такие страшные вещи, как AWS, AZ, DC/OS и Docker.

Сначала про AWS. В далеком 2004-ом году компания Амазон придумала очень интересный бизнес. По миру были (и есть) распространены различные хостинг-провайдеры, у которых можно арендовать оборудование - серверы (физические или виртуальные) и сеть (свичи, маршрутизаторы и т.д.). Амазон решил зайти еще дальше - он стал предлагать предустановленные системы в качестве услуг.

Проще говоря, если вам нужна маленькая база данных на MySQL или Oracle, вы, вместо того чтобы установить все сами (заказать сервер, поставить ОС, поставить туда СУБД, наладить резервное копирование, мониторинг и прочее), заходите на прикольный веб портал, кликаете по нужной СУБД, выбираете размер, идете за кофе, и, когда вы вернетесь, база данных будет готова и ждать дальнейших распоряжений.

У AWS сейчас сотня различных сервисов, от виртуальных серверов и СУБД до сопровождаемых (не вами, что самое прекрасное) очередей сообщений, кластеров для анализа BigData и даже удаленные рабочие столы и CDN.

Для того, чтобы предоставлять вам определенное удобство управления и планирования ресурсов, Амазон создал модель регионов и “зон доступности” (далее AZ).

Регион - определенная географическая область, на которой Амазон предлагает свои услуги. Может считаться как отдельный город, штат или страна. Регионы именуются по стране или географии, “области” и порядковому номеру. В тех же США у Амазона 4 региона - Северная Вирджиния, Огайо, Северная Калифорния и Орегон. Эти регионы именуются как us-east-1, us-east-2, us-west-1 и, ВНЕЗАПНО, us-west-2. Регионы есть и в Европе, например Ирландия (eu-west-1) и Франкфурт (eu-central-1). Делается это для географического удобства (если вы сидите в Амстердаме, то до сервера в Лондоне добраться быстрее, чем до сервера в Австралии) и для соблюдения законов в странах, где вы хотите вести бизнес. Каждый регион состоит из нескольких AZ.
AZ (availability zone, зона доступности) - это один или несколько ЦОДов (центров обработки данных), которые работают независимо друг от друга, но обладают высокоскоростным соединением между собой. Делается это также для отказоустойчивости - если один из AZ придет в негодность, у вас есть еще 2 (или даже больше) ЦОДа.

Теперь немного технических деталей. Когда вы создали аккаунт на AWS и привязали к нему свою кредитку (Амазон берет плату по поминутной тарификации использования их услуг), вы создаете VPC (virtual private cloud) - этакий “свой” ЦОД внутри ЦОД Амазона, привязанный к определенному региону. Серверы и базы данных в дальнейшем будут ставиться как раз на этот самый VPC. Внутри VPC вы создаете “подсети” (subnets), которые живут внутри вашего VPC и привязываются к определенной AZ.

Да, это может звучать сложно, поэтому перечитайте этот пост несколько раз ну или сходите на сайт AWS и прочитайте все из первоисточника.
Вся эта информация важна, потому что из нее следует первая проблема, с которой я столкнулся.

Когда вы создаете VPC вы указываете большую сеть (до нескольких десятков тысяч IP адресов). А когда вы создаете подсеть, то в ней вы задаете сеть поменьше, которая в свою очередь является частью большой сети.

Так вот мои прекрасные коллеги в регионе с 3 AZ сделали 3 подсети - 2 маленьких (не знаю зачем) и 1 большую (ЗАЧЕМ?!), в которой и “сидит” бОльшая часть нашей инфраструктуры. Помните, что подсеть привязана к AZ? Первая проблема в том, что если эта самая AZ отвалится, то и 80% нашей инфраструктуры повалится вслед за ней. Люблю своих коллег.

Теперь к моей задаче - мне нужно развернуть отдельный кластер DC/OS для так называемого “тулинга” - ряда небольших (или больших) систем, которые помогают нашим разработчикам и бизнесу делать свое дело. Под тулинг можно подвести системы мониторинга, логгирования, несколько велосипедов, написанных нашими силами, TeamCity (система сборки, тестирования и развертывания ПО) и прочее.

Сегодня мы с шефом поставили все точки над i по поводу моих целей на 2018 год. Цели у меня следующие:
- получить AWS Certified Developer Associate
- закрыть пробелы мониторинга, согласно Definition of Health
- имплементировать zero downtime deployment.

Самая интересная цель, пожалуй, третья.
Читатель, знакомый с такими методами, как Canary или Green/Blue deployment, решит, что это легко.
Инженер, проработавший с Kubernetes, решит, что это еще проще. (Kuber такое делает вообще из коробки)

Но мое положение немного отличается, так как в стеке у нас DC/OS и Marathon.

Поэтому мою задачу можно решить разными способами: от заменой Марафона Кубером до написания собственных велосипедов по Green/Blue.

Это, кстати, эталонный пример условной Вундервафли, о которой я так люблю писать, но раз уж у меня есть целых 9 месяцев, чтобы это сделать, я распишу весь процесс (от техники до менеджмента) гораздо позже. А пока в качестве условно сложного проекта я представлю вам задачу под названием “DEVOPS-74 DC/OS Tooling environment”, которая свалилась на мои плечи позавчера, и по которой я провожу исследование, что тот ученый сын маминой подруги. Уверен, вся история покроет две темы, запрошенные моими читателями раньше (https://t.me/manandthemachine/178)

Завтра распишу изначальную постановку задачу, и как я ее разжевывал. Stay tuned.

К слову о профессиональной депрессии: если вы иногда начинаете сомневаться в своей компетентности и образованности, знайте, что в мире существует прекрасная организация.

Простите дуру грешную, я забыл о самом главном. Но сначала немного городских легенд.

Мне рассказали байку о том, как контора Стива Джобса делала мышь без кнопок. У дизайнеров было несколько прототипов, в том числе и с кнопками, и когда Джобс проходил мимо их комнаты, он, увидев кнопочные мышки, влетел в кабинет и начал на всех орать. Ему пытались объяснить, мол это прототип, мы еще сто раз это переделаем, а он психанул, разбил мышь и ушел с криками: “Никаких гребаных кнопок!”

За достоверность истории я отвечать не берусь, Джобсу руку не жал, в Купертино не ездил, в кампусе Apple не гулял. Про Джобса много уже наговорили, и хорошего, и плохого, но у истории с мышкой есть одна важная мораль - остановиться, когда направление неверно.

Это очень сложно делать, и особенно эту боль чувствуешь, когда работаешь со старыми системами, т.н. legacy. Мой предыдущий работодатель написал свою ERP/CRM/итд на Delphi, назвав ее Ванесса. Через эту самую Ванессу велось 90% бизнеса, и когда Ванесса располнела совсем, а сопровождать и дорабатывать ее стало очень тяжело, начали думать. Чтобы выбросить на помойку 10 лет разработки и несколько миллионов строк кода не хватило политической воли, поэтому решили оставить все как есть, а вокруг Ванессы строить микросервисы, которые либо заменяли, либо дополняли функционал.

Когда я только приступил к своим обязанностям, мне это казалось вполне логичным, но вот казус - самые критические сервисы (платежи, база клиентов, база учета товаров), весь core business делался и делается через нее. Контора до сих пор нанимает разработчиков Delphi, которых днем с огнем не сыщешь.

Или вот еще момент: когда я работал в Рено, руководил (да и до сих пор руководит, как мне говорят бывшие коллеги) над нами прекрасный солнцеликий Денис Г., который отличался импульсивностью и, по моему скромному мнению, нуждается в курсах управления гневом. С Денисом никто напрямую работать не любил. Если Денис слышал что-то неприятное его чутким ушам, он начинал размахивать руками, перебивать и предлагать свое (ОСОБЕННО в тех местах, где он ничего не понимает). Один из системных архитекторов согласился на его присутствие в митинге только если тот будет молчать первые полчаса brainstorm’а. Дениса хватило минут на 5.

Про Дениса тоже можно сказать много хорошего и плохого, с ним (как и, я уверен, со Стивом Джобсом) работать тяжело, неэффективно и неприятно. Но у таких товарищей есть полезный талант перекрывать кислород заведомо пагубным идеям и предложениям.

К чему я все это - теперь, когда я дорос до определенного уровня, я начинаю понимать их мотивацию. Когда работаешь над какой-то задачей, и решение занимает много времени (или вообще не работает), нужно остановиться, отдышаться, сделать шаг назад, стереть все к чертям, и начать все с чистого лица. Не удивляйтесь, если не будет получаться с первого раза. Пускать часы и дни работы в молоко очень больно, обидно и опасно (может привести к профессиональной депрессии под названием “Я ни на что не способный идиот”).

Когда попадаете в эту ловушку, делайте следующее:
- Заблокируйте свой компьютер.
- Сделайте несколько глубоких вдохов и выдохов.
- Встаньте со своего кресла.
- Отправьтесь на кухню/столовую/ближайшее кафе.
- Налейте себе чашку кофе/чая.
- Посмотрите в окно. Если нет окна посмотрите на окружающих вас людей.
- Спросите соседа, как прошли его выходные, либо о планах на ближайшие. Расскажите о своих.
- Допейте свой напиток и возвращайтесь на рабочее место.
- Пробуйте снова.

При необходимости - повторяйте.

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

А пока еще раз напоминаю, что все вопросы и предложения можно смело слать на @ThomasStorm

Приступим к можно (а точнее НУЖНО).

НУЖНО:
- Учиться. Я уверен, вы слышали из каждого утюга, как надо много много учиться, и, к сожалению, это правда. Со скоростью развития технологий, чтобы стать первым парнем на деревне придется очень много и очень быстро учиться. К счастью, многие сервисы предлагают определенный free tier, когда можно пробовать систему в промышленной эксплуатации, не заплатив ни копейки. Впрочем, я настоятельно рекомендую инвестировать в собственное развитие хотя бы 10 евро в месяц.
- Предлагать что-то новое. Какой бы идеальной ни была компания и продукт, всегда можно что-то сделать лучше.
- Не бояться ошибок и экспериментировать. Не бойтесь тратить время на освоение новой технологии, обкатывайте ее локально и в тестовом окружении. Даже если все время будет потрачено впустую, вы получите бесценный опыт.
- Критически относиться ко всему новому. Все модные свистелки и перделки были в основном придуманы крупными компаниями: Kubernetes, он же Borg, был придумал Гуглом для Гугла, ReactJS и GraphQL придумали в Facebook, kPHP во Вконтакте. То что кто-то что-то написал и успешно внедрил у себя, не значит, что это подойдет вам. Тот же Амазон перенес инфраструктуру своего бизнеса на AWS только в 2010-ом году, когда тот функционировал уже лет 6, а Фейсбук все еще сидит на своих ЦОД’ах и уходить от них не планирует.
- Отталкиваться от нужд бизнеса. Когда вас просят спроектировать облачную инфраструктуру, посмотрите на это со стороны бизнеса. В каких странах планируется “продавать” продукт? Как там обстоят дела с регулированием? Сколько планируется привлечь клиентов? Какой ожидаемый рост данных? Что делать с архивными данными? Ответьте на эти вопросы сейчас, чтобы не рвать на себе волосы потом.
- Думать о расходах. Хороший архитектор отличается от плохого тем, что его решение будет таким же крутым. но еще и дешевле.
- Не бойтесь делегировать и просить о помощи. Как я уже писал раньше, опытный инженер знает нечто (сервер, СУБД, сервер приложений) лучше вас, и это НОРМАЛЬНО.

Список можно продолжать бесконечно и важно понимать, что это не silver bullet. Даже если вы освоите все хард и софт навыки, вам все равно не гарантируется должность.
К сожалению, наш мир настолько неидеален, что вам вообще ничего и никогда не гарантируется.

Теперь о третьем - чтобы стать архитектором, нужно БЫТЬ архитектором.

Вам может показаться, что это звучит странно, поэтому я распишу что делать можно и нельзя, чтобы обрести необходимый архитекторский склад ума.

НЕЛЬЗЯ:
- Спешить. Нередко талантливый спец сталкивается с проблемой, созданной им самим, потому что в свое время неправильно оценил объем труда или задачу как таковую. Подходите критически к задаче. Если вас попросят построить дом, прежде чем закладывать фундамент, оцените сколько людей в нем будет жить, сколько этажей надо и какое количество ванных надо предоставить.
- Хвататься за несколько задач одновременно. Проектирование требует жесткого фокуса на цели. Если будете отвлекаться на все задачи подряд, уведомления мессенджеров и входящую почту, то легко забудете, что и зачем вы делаете. Выключите звук на телефоне. Спрячьте открытые Вконтакте и Фейсбук. Поставьте музыку на паузу. Спрячьтесь в переговорке, где вас никто не тронет. Положите перед собой лист бумаги и ручку и займитесь своим делом.
- Соглашаться на все требования. Внедрение любого решения требует ресурсов, будь то деньги, время или люди. Продумайте что от вас требуется, прикиньте сколько времени и рук нужно на решение задачи. Если задача кажется слишком большой - разбейте ее на несколько этапов. Если вас просят собрать вундервафлю за пару часов, говорите “НЕТ”. Если к вам подошел разработчик и просит вставить небольшой скрипт в CI/CD, говорите “НЕТ”, пока не убедитесь, что этот скрипт не ломает всю структуру.

Собрав все воедино, могу сказать, что чаще всего из ваших уст будут сыпаться слова “нет” и “почему”.

Неважно, какая у вас должность и уровень опыта. Никакие титулы, иерархия и размер заработной платы не мешают вам думать.

Про первое отличие поговорили, приступим ко второму - кругозору.

Инженер знает что-то свое и знает хорошо (иногда ОЧЕНЬ хорошо). Именно поэтому архитектор не всегда лучше - в свое время хардкорный инженер IBM WebSphere мог расчитывать на такую зарплату, которая обычному ИТ архитектору и не снилась.

Сейчас мир неумолимо движется в сторону облачных вычислений и managed services, которые гораздо проще развернуть без определенных навыков. А раз у нас есть сотни разных прикольных штук (баз данных, брокеров сообщений, систем рассылки и приема электронной почты, серверов, поднимаемых буквально в 2-3 клика и т.д.), которые и администрировать даже не надо (на самом деле надо, но это не ваша проблема) - то и требования к специалисту растут.

Тот же экзамен AWS Certified Solution Architect Associate подразумевает, что вы знаете как минимум 2-3 языка программирования, умеете работать с Windows и Linux, знаете BigData, Hadoop, Enterprise Service Bus, Application Architecture, OOP/FP , RESTful API, TCP/IP, VPN… очень много.

Казалось бы, чтобы реально ЗНАТЬ вот это все понадобится угробить 15-20 лет на опыт и успеть побыть в шкуре как сисадмина, так и разработчика.
И по сути архитектор и есть такой парень. Но раз системы стали проще, то и порог в годах становится меньше.
В итоге и получаем, что архитектор знает немного обо всем.

Вторым важным дополнением к кругозору является активность в сообществах. Нужно (вот реально нужно) гонять на всякие конференции и митапы, участвовать в вебинарах, сидеть на форумах и чатиках (Отдельно даже приветствуется участие в open source проектах).

Получаем 3 неоспоримых преимущества:
- узнаем “как там у них все работает”, очень полезно, когда можете узнать инфраструктуру коллеги по цеху без необходимости приему на работу.
- занимаемся пошлым занятием под названием networking - обрастаем всякими связями, налаживаем контакты.
- зарабатываем необходимый навык менторства - архитектор, помимо всего остального может поделиться мудрым советом или наставить на путь истинный.

Казалось бы, звучит это все как детский сад. Вроде умеешь себе серверы настраивать да со всякими там pipeline’ами - уже хорошо, без работы не останешься.

Забудьте. Работать с людьми придется, валяться в политике придется, донести до некомпетентного менеджера свою точку зрения придется.

Все придется делать.

А кто не хочет… ищите мой пост про сисадмина средней руки в “ООО Рога и Копыта” на 100 человек.

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

Прежде чем описать такого персонажа как Solution(s) Architect (далее SA) надо для начала пояснить принципиальные отличия между инженером и архитектором. Писать тут очень много, поэтому буду разбивать

Эти отличия в принципе подходят для всех ролей, например:
- Software Engineer -> Software Architect
- System/Infrastructure Engineer -> Infrastructure Architect
- Database Administrator -> Database Architect
- DevOps/Site Reliability Engineer -> Solutions Architect
- Cloud engineer -> Cloud architect

Пусть эти стрелочки не вводят вас в заблуждение - архитектор не всегда “лучше” инженера.

Я уже писал ранее, что архитекторы и инженеры работают (и должны работать) по-разному. Разница начинается уже в процессе onboarding (когда новый сотрудник только вышел на работу). Обычно инженеру, в зависимости от его основной роли, показывают его землю обетованную, продукты и проекты, знакомят с командой (иногда знакомят с другими командами, в зависимости от размеров конторы), помогают настроить рабочую станцию, системы и вводят в курс дела.

Условный сферический конь в вакууме (будь он Windows или Linux инженером) потратит первые месяцы на изучение конкретно своего (и зачастую только своего) домена (Под доменом понимается зона его экспертной оценки). Проще говоря Linux человечек не полезет в дебри Active Directory или SCCM. Он дойдет до этого (особенно в Scrum команде), но очень нескоро.

Архитектору же положено узнать все - от бизнеса компании и структуры организации до ВСЕХ продуктов и ВСЕХ процессов. Вот тут и кроется главная заковырка - изучить надо все, но запомнить все при этом будет невозможно. Остается достичь какого-то определенного абстрактного “понимания”, как все работает, и, поверьте, это далеко не самое главное. Не ждите, что с вас реально спросят как компоненты работают между собой. Это так же глупо, как спрашивать профессионального ретушера рассказать абсолютно все функции Adobe Photoshop.

Гораздо важнее на стартовом этапе понять не “как оно работает”, а какие причины и история стоят за выбранными системами и технологиями. Одним из моих основных вопросов на собеседовании был “почему”. Знать “почему” гораздо важнее, чем “как” и “что”. Это - первое отличие архитектора от инженера.

Узнав историю, вы сможете понять в каком (плачевном) состоянии находится контора и ее продукты и почему, и как с этим жить и что делать дальше. Запомните и запишите, поскольку это очень важно.
Архитекторов не нанимают, когда все хорошо. (На собеседовании вам об этом, разумеется не скажут, иначе можно спекулировать на зарплате)

Есть большая разница между празднованием 8-ого марта в России и в Европе.

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

Так, например, одна дама менеджер любит выкладывать фотки с конференций в стиле “Женщины в ИТ” и “Женщины в менеджменте”. Другая участвовала в инициативе по привлечению женщин не из ИТ сферы, преподавая им программирование на Ruby (не знаю почему, но в Нидерландах очень любят Ruby).

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

Я не могу сказать, что очень жалую “гендерные” праздники. Праздновать 8 Марта, потому что ты выступаешь против “хуемразей” и “спермобаков” (или как там мужчин еще называют в интернете), тоже самое что праздновать 23 Февраля, потому что ты поймал пулю в Афганистане. Так себе повод, если честно.

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

Чего и вам желаю.

Между делом вновь прибывшим и старичкам напоминаю - идеи, критику, вопросики и пожелания смело отправляйте в телеграм (@ThomasStorm) или на почту thomas.storm@protonmail.com

Подписоты привалило. Люблю такое, надо почаще сидеть на тематических форумах и чатиках. 🙂

Я уже писал раньше, что сменил место работы - теперь я уже не рядовой инженегр, а самый, что ни на есть, Архитектор. Если быть занудой, Архитектор Облачных Решений.

Тут, надо заметить, есть колоссальная разница. Инженер, будь он самым крутым, умным и сильным, собирает новые решения сам, вот этими самыми руками.

У меня опыт с архитектурными проектами был и раньше. Как правило, там приходилось рисовать диаграммы, защищать бюджет, набирать команду, да всеми руками это дело внедрять и собирать.

В последний раз с архитектором я работал в CoolBlue, на своем последнем серьезном проекте по автоматизации выдачи ноутбуков (о чем я уже писал ранее). Парень, часовая ставка которого была 200 евро, за 3 дня со мной на пару собрал вундервафлю, после чего сделал ручкой и растворился с тумане Роттердама.

Тогда я для себя решил, что архитектор это такой нереально умный человек, который знает все и про все (ну или хотя бы 90%). Разумеется таких людей не существует на свете (а те, кто считает себя таковыми - лжецы и подлецы), поэтому логично их разделять на области. Например, архитектор по серверной инфраструктуре, архитектор информационных систем, архитектор баз данных, архитектор сетей и дальше по списку. Но самая заманчивая тема, на которую я буду делать ставку в своей карьере, это архитектор решений (с буржуйского Solution Architect). Почему - напишу чуть позже, надо правильно сформулировать мысль.

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

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

В итоге весь свой испытательный срок я не открывал на своем компьютере ничего тяжелее офиса и браузера. Прав у меня хватало ровно на Read (смотреть можно, трогать нельзя), а работал я больше не руками, а языком - поговори с этим, поговори с тем.

После 2 месяцев этакого похода в ИТ стриптиз клуб, наглядевшись на окружающую меня порнографию, я подготовил 4 20-страничных документа - по безопасности, по процедуре CI/CD, по мониторингу и логированию, а также горячо любимые сердцу Definition of Ready и Definition of Done (люди, работающие по Agile поймут).
Итоговым выхлопом из этой документации стали более десятка story по improvement’у.

Коллега же нашел в текущей инфраструктуре столько изъянов, что волосы встают дыбом. Чего только стоят API вызовы по HTTP и 20 аккаунтов разработчиков в Амазоне в FullAdminAccess.

Год обещает быть очень веселым. 🙂