Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

DevOps простыми словами: как IT-команде делать важное и зарабатывать больше

Статья написана в соавторстве с Андреем Баулиным, Head of DevOps продуктовой IT-компании Megogo.

Разбираемся, почему попытки «внедрения DevOps» не имеют смысла без конкретной цели и как оптимизировать работу IT-компании, когда цель есть.

В разных технических коллективах можно встретить различные формулировки DevOps и их навыков. Большинство сводится к тому, что это некий человек, который находится «в одной комнате» с development и IT operations (иногда еще QA) и согласовывает их работу. Конечно, такое определение очень и очень условно.

В технологических стартапах с малым количеством людей не программирующий девопс — нонсенс. Зачем он там? По сути, в таких командах ops — маленькие буквы в конце, а DEV — большие в начале. В устойчивых командах среднего размера OPS набирают обороты, а девов и так много, поэтому «удельный вес» букв заметно меняется.

Мы никогда не ставили перед собой цель «внедрить DevOps» или «нанять девопсов». Потому что — ну кто это? Почему они должны сделать нас лучше всех? Чем они отличаются от тех людей-оркестров, которые в компании и так были всегда? Мы создавали команду мотивированных операционистов, знающих и углубляющихся в логику продукта, работающих бок о бок с девелоперами и тестировщиками. И потом констатировали, что многие в глобальном IT-сообществе называют таких людей девопсами.

Зачем нам DevOps

DevOps — это набор практик и инструментов, они должны решать реальные задачи. Молоток нужен, чтобы забить гвоздь. Сначала вы определяете цель, а потом уже ищете инструменты.

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

Нам не нужны люди с титулом DevOps и умением рассуждать о Kubernetes 20 минут подряд, если они не умеют объяснить, как TCP-пакет попадает из одной OS в другую.

Мы продуктовая компания, и всё у нас крутится вокруг продукта. У нас никогда не было «системных администраторов», потому что не было таких систем, которые имели бы смысл и ценность без продукта. В начале 2010-х, когда мы выходили на рынок, в продуктовых компаниях сисадминами были люди, прекрасно понимающие как бизнес-логику своих продуктов, так и сложности их массовой поставки и обслуживания в продакшене. Такие же люди сейчас становятся хорошими девопсами: понимающие, что, как и для чего делать.

Мы не ставили перед собой цель «внедрить DevOps». Вместо этого задали себе вопрос: что нам нужно в operations и кто это может реализовать. Ответ получился из трёх частей: люди (команда), подход к работе IT operations и среда.

Что (и кто) делает команду эффективной

Для начала мы описали людей, которых хотим видеть в коллективе: их hard и soft skills, майндсет и работу всей команды целиком. Вот признаки, которые получилось выделить:

  • Структура должна быть как можно более плоской, никаких начальников. Операционистов не должна волновать политика. Они не должны думать о том, «кто попросил это сделать», и оценивать задачи, основываясь на иерархии. Законно то, что логично. «Более прав» тот, кто лучше обосновывает.
  • Люди должны быть самостоятельными. Соотношение goal driven против process oriented среди сотрудников должно быть максимально в пользу первых, но для баланса нужны и вторые.
  • Они должны уметь костылять как боги! Но и вести счет «костылям», и правильно писать их в технический долг.
  • Cloud-навыки для нас менее важны, чем on-premise. Человек, умеющий превратить on-premise DC в приличный private IAAS, в наших глазах ценнее ловкача в AWS-среде, к примеру.
  • Важны хорошие навыки в темплейтизации, тяга к ней. Вот чтобы хлебом не корми, а дай увидеть темплейт в разрозненных сущностях и процессах.
  • «Автоматизация» и «аксиома» не должны быть синонимами в голове операциониста. Собственно, возвращаемся к третьему пункту: они должны уметь костылять как боги!
  • Логика важнее преемственности. На интервью в игровых технических заданиях мы стараемся поставить человека в ситуацию, в которой он не может выехать за счёт энциклопедических знаний. И смотрим, как он думает в этих условиях, умеет ли объяснить ход своих мыслей. Кстати, разрешаем брать на интервью телефон с интернетом и гуглить.

Какими характеристиками должен обладать IT operations

  • Продукт использует пользователь. И он должен быть доволен. У нас не в ходу фраза «ну пускай кто делал, тот и разбёрется». Наш operantions — «затычка» в любой боли, которой ещё не найден конкретный хозяин.
  • Удобно — это прозрачно и интуитивно. Чем меньше надо помнить и знать о сервисах и системах, тем лучше. В идеале — ничего не надо помнить и знать о сервисах. Но прозрачно и интуитивно — не равно небезопасно (об этом ниже).
  • Мы не планируем на годы вперед, но все-таки планируем. И мы не тратим на планирование существенные ресурсы, экономим время.
  • Если кто-то хочет попробовать новый продукт — он просто ставит себе задачу и устанавливает PoC. Потом рассказывает другим.
  • Новые сущности в продакшене появляются по двум причинам:
    а) это можно нарисовать и уложить в описанную схему: всё должно отвечать на вопрос, «как создать ещё сто таких, чтобы было одинаковое и удобное»;
    б) потому что надо «вот прям щас», нужно ловить момент.
  • Меньше совещаний, больше ad hoc (то есть меньше групповых совещаний, больше конкретных технических диалогов и споров).
  • По возможности, отсутствие неинтерактивных коммуникаций (вроде имейлов).
  • По возможности, присутствие тикетной системы.
  • Чем раньше ops появится среди dev во время реализации чего-то нового, тем лучше. В идеале — успеть с самого начала. Поэтому, вместо работы над единым пулом задач, наши ребята работают каждый в своих девелоперских командах.
  • В клиент-саппорте эджайлу — нет. Если оставить телефонный саппорт с клиентами наедине, то никакого улучшения качества не будет. В этой области ITSM-подход — наше всё: разделение на уровни L1-L2-L3, по возможности — независимый инцидент и проблем-менеджмент, работа со статистикой инцидентов... Мы вкладываем ресурсы в это и всё сильнее «закручиваем гайки». Кстати, в Megogo с клиент-саппортом тесно связан мониторинг и алертинг.
  • Безопасность должна быть прозрачной. Она не в сокрытии информации, наоборот! И она не должна обременять operantions. Это вовсе не означает, что безопасностью можно пренебречь или нарушать принцип defense in depth. Это означает, что безопасность, — реализовывает ли её в каком-то случае dev, DevOps или SecOps, — не должна ломать дизайн, процессы и процедуры во имя себя самой.

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

В какой среде люди работают эффективно

Какими характеристиками должны обладать среды, чтобы описанные выше люди, работающие в описанном выше стиле, могли их эффективно администрировать и разрабатывать?

  • Infrastructure as a code.
  • В рамках разумного — горизонтальное масштабирование и динамическое всё: каталог сервисов, service mesh и т. д.
  • Меньше веб-морд, ещё меньше! Консолидируем.
  • Если во время дизайна в графе «сценарий восстановления» стоит выбор между «пересоздать» или «из бэкапа», то нужно выбирать первое. Однозначно.
  • Прозрачные структуры можно документировать менее подробно, а то и вовсе не документировать, достаточно скетчей (поэтому у нас сильно ругают за отступы от нейминг-конвенций и тому подобные «мелочи»).

Когда мы все это сформулировали, оказалось, что многое из вышеперечисленного подходит под манифест agile в целом и DevOps в частности. Тут очень важен порядок: мы не внедряли у себя agile-философию. Мы работали, вычленяли наиболее эффективные подходы — и обнаружили, что наша философия так называется.

DevOps-инструменты — это абстракция

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

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

В интернете полно статей на тему «в компании Х используют Y». Но вас не должен интересовать тот факт, что такой-то бизнес использует Prometheus, Grafana или что-то ещё. Вам должно быть интересно, насколько данная компания похожа на вашу, какие задачи решает и почему именно этими решениями. Нужно смотреть, из чего выбирали, как долго используют, чем ещё из подобных продуктов пользуются, насколько глубоко внедрение. Может, уже собираются отказываться от этого инструмента. В общем, вам нужны мелочи. А названия самих продуктов не нужны. Сформулируйте конкретную проблему и ищите, какие инструменты её решают.

И даже если вам повезёт увидеть список нормальных инструментов, какая в нём ценность? Любые инструменты сегодня устаревают так быстро, что нет смысла их перечислять.

Какие выводы можно сделать из всего этого

Никакой «инструкции» по внедрению DevOps не существует. Более того, она не имеет смысла. Нет единой системы, по которой нужно организовывать DevOps в компании. У нас, к примеру, есть «девопсы девопсов» — некая core-команда, которая разрабатывает общие для всех команд вещи. Но в целом это виртуальная структура: системные задачи и субпроекты кочуют от человека к человеку. Нет отдельно техсаппорта и девопсов. В Megogo девопсы не потеряли ITIL-классификации сисадминов, как L3 техсаппорта.

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

Ещё раз: нет никакого «пошагового плана внедрения DevOps». Но если всё-таки попытаться сформулировать общие советы, то их всего два:

  1. Не бойтесь переделывать. Очень большая ошибка — делать рефакторинг работы во всём и всегда. Потому что переделывание — это, по сути, есть жизнь.
  2. Трезво оценивайте цену ошибок. Часто совершить ошибку дешевле, чем не допустить её.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



14 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спорная, контекстно зависимая статья. В выводах 2 пункта: не бойтесь переделывать, оценивайте цену ошибок. Из серии «как стать поваром», с выводами: «нож острый, не порежьтесь» и «нет универсальных рецептов пасты». Статья ради пиара.

как TCP-пакет попадает из одной OS в другую

щито ?

интересно услышать обЪяснения товарищей которые успешно прошли собес ...

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

Безопасность должна быть прозрачной. Она не в сокрытии информации, наоборот! И она не должна обременять operantions. Это вовсе не означает, что безопасностью можно пренебречь или нарушать принцип defense in depth. Это означает, что безопасность, — реализовывает ли её в каком-то случае dev, DevOps или SecOps, — не должна ломать дизайн, процессы и процедуры во имя себя самой.

1. Безопасность не может не обременять operantions. Если ты хранишь номера банковских карт пользователей — будь добр зашифруй диск и бекапы. Со всеми вытекающими накладными расходами типа рекавери ключей.
2. Круг людей в одной компании которые понимают принцип defense in depth настолько мал что можно на пальцах одной руки пересчитать. У вас все Dev-ы в компании его знают? А если ты о нем не слышал — ты его будешь нарушать. Часто именно изза этого непонимания Dev-ы, PM-ы и Top-ы ноют что безопасники замыкаются сами на себе и производят правила, смысла которых уже не могут чётко и ясно объяснить. Они могут все обьяснить короткой фразой: «это основной принцип defense in depth»

В Megogo девопсы не потеряли ITIL-классификации сисадминов, как L3 техсаппорта

т.е. по вашему определию девопс must have ITIL. Какой же это девопс? это просто прокачанный сисадмин.

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

Сколько статей про девопс — столько трактовок что такое девопс. Сколько девопсов — столько трактововк в назначении, специализации, задачах, полтике и прочем....

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

Вот глупые рекрутеры, вместо того, чтобы нанять сисадмина за 1к, они нанимают девопса за 3.5к.
Конечно же, разница только в названии.

А чего вас так это удивляет ? Посмотрите сколько вакансий на позицию девопс инженер, все сводитя к одному — поддержка инфраструктуры. Есть так же какие то попытки внедрить какие то непонятные никому методологии — кроме того кто придумал методологию, придуманные философии девопс и прочее подобное. Что в целом все равно сводится к тому, что это человек который что то делает с инфраструктурой, что опять же приводит к тому что это сисадмин, только не тягающий кабеля и строящий инфраструктуру в амазоне или gc, вместо дедиков и виртуалок. То что раньше сисадмин нах...й посылал когда в очередной раз к нему с очередной бредней приходили, то теперь рассказывается что девопс это когда сисадмин культурный и не посылает никуда, да еще и помогает )))) Собственно за это имхо доплачивается.

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

Никакой «инструкции» по внедрению DevOps не существует

\
Не существует вообще никаких инструкций, ведущих к успеху.
Есть только рекомендации по общим ошибкам, которые надо избегать. Хороший пример — техника безопасности.
Плохой пример — это «10 Шагов к успеху вашего Бизнеса, от которого все будут в шоке!» основанная на «ошибках выжившего» — это когда на основе успеха одной компании делают тренинги и не включают разорение идентичных 99 компаний.

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

Хорошая статья. Но.

>Структура должна быть как можно более плоской, никаких начальников. Операционистов не должна волновать политика. Они не должны думать о том, «кто попросил это сделать», и оценивать задачи, основываясь на иерархии. Законно то, что логично. «Более прав» тот, кто лучше обосновывает.

Политика начинается тогда, когда нет структуры. Если нет человека который решает, тогда побеждает тот кто громче кричит. То что у вас крик измеряется логикой — ничего не решает. Рассуждайте так — есть заказчик, а есть исполнитель. Если к вашим исполнителям приходят два заказчика, то как исполнитель должен решить чью работу делать? Почему это должен решать исполнитель? Каким образом инженер может знать всё о том что надо продукту в конкретный момент и что важнее для продукта конкретно сейчас?
В маленьких бизнесах справедливо требовать от инженера знания продукта, но на самом деле это менее эффективно чем иметь продукт менеджера, который знает что надо продукту и который (которая, которые) является принимающим решение.

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

>Люди должны быть самостоятельными. Соотношение goal driven против process oriented среди сотрудников должно быть максимально в пользу первых, но для баланса нужны и вторые.

Если вы выбраковывете людей тоннами, то goal driven ок. Задачи заканчиваются, надо оттачивать и улучшать. Я, как представитель goal driven людей отлично понимаю что я слаб в шлифовании и улучшении и поэтому часто нанимаю себе в команду именно process oriented person. Иначе всё быстро запилим, а потом все сидят выгорают над имплементацией и полировкой.

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

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

>Продукт использует пользователь. И он должен быть доволен. У нас не в ходу фраза «ну пускай кто делал, тот и разбёрется». Наш operantions — «затычка» в любой боли, которой ещё не найден конкретный хозяин.

Справедливо. Но если нет овнера, то как понять какая «боль» приоритетнее?

>всё должно отвечать на вопрос, «как создать ещё сто таких, чтобы было одинаковое и удобное»
противоречит нелюбви к автоматизации. Опять же, надо ли всегда думать о том как создать «сто таких» или иногда достаточно иметь какие-то супер уникальные штуки?

>По возможности, отсутствие неинтерактивных коммуникаций (вроде имейлов).

Имейлы важная часть общения, когда нужен не срочный, но обстоятельный ответ.

>По возможности, присутствие тикетной системы.

интересно, а когда тикетная система не нужна?

В общем статья хорошая и имплементация интересная, особенно если работает, но если честно иногда складывалось ощущение что вы забыли что единственный ключевой слоган девопс это единство приоритетов. Если у вас есть человек который разруливает приоритеты для ops и dev команды и сразу все команды отвечают за стабильность и за time to market, то это девопс. Если у вас такого человека нет, то девопс тоже может быть, но только до тех пор пока у всех в головах есть одинаковое понимание соотношения time-to-market и стабильности. Хотя, если честно, я наблюдал только случаи, когда начиная с двух человек одинакового понимания уже не было, была иллюзия одинакового понимания, которую было очень легко разбить.

Привет!

Я тот персонаж, который упомянут в соавторстве.
Некоторое время я прокрастинировал с ответом, что было не вежливо — всё же, обстоятельный, развёрнутый комментарий. Человек потратил своё время на чтение и анализ, и это действительно ценно. Спасибо за него.

Но пока я откладывал, я так же и думал, как же ответить на те части, с которыми не согласен. Как обозначить то, с чем согласен, и чтоб всё это уложить не в 30 А4 печатных листов.... И отвечу я вот как:

1. Вы разворачиваете полемику, не дискуссию: некоторые контр-доводы, мягко-говоря, требуют обоснования, прежде чем нам, как авторам, отвечать на них.
2. Текст коммента показывает, что Вы опытный полемик. Я уважаю и опыт, и полемистов. Полемистов, потому что сам этой породы — считаю, что никто так не близок к правде как тот, кто искажает её в споре умело и намеренно. Потому что нельзя исказить то, о чём ты не имеешь понятия.
С навыком спора приходит гибкость мышления и осознание условности реального топика полемики. Выработать форму и гибкость доводов — единственная практическая польза споров, на мой взгляд. Не достигнуть взаимопонимания. Часто, в полемике она и так есть, люди имитируют несогласие ради самого процесса. Надеюсь, что ко всему последующему тексту Вы отнесётесь, держа в уме этот мой абзац.
3. Спор, который мы тут можем развернуть, на много интереснее пройдёт в устной форме. Под не плохой односолодовый. Потому приглашаю сменить формат в эту плоскость ;) Возможно, мы высечем новые искры правды... ну, и продегустируем что нибудь улучшающее пищеварение!

Однако, при всём моём желании совместно прибухнуть, есть 2 момента, на которые хотелось бы обратить внимание ответным письменным текстом:

1. Вы парируете, что темплейтизация это очень опасно, и приводите в пример что-то мне не понятное. Пытаясь угадать, зачем тот безымянный девоп из примера пытался такое наваять, я предположил, что он накидал костыль для вебхуков... впрочем, не важно, что это было, really.
Важно, что с Ваших слов я вообще не понял, почему любить темплейтизацию опасно. Вы можете как-то более развёрнуто аргументировать своё возражение? И учесть, при этом, явно заложенную в парент тексте двойственность: «темплейтизацию надо любить, но костылять надо уметь»?

2. «забыли что единственный ключевой слоган девопс это единство приоритетов»

Эмммм... нет, мы не забыли. Мы этого даже и не помнили.

Каков контр-аргумент, такая и линия защиты: у меня сложилось мнение, что вы натянули новые слова на старую оболочку. ОК, на словах вы заменили итильных сисадминов на девопов. Но они по прежнему априори дети малые, которые не могут определить с той же точностью, что и задуманные для этого некие позиции компании, что же реально нужно в их части периметра. И не нужно тратить время на их мнение. Загасим его овнерами, тим лидами и микроменеджментом (что, кстати, всё равно нужно). Им нужен кем-то напиленный бэклог, спринты и батя, за этим всем смотрящий — потому что ну он же лучше знает, в конце-то концов. Он проконтроллирует.

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

Для меня это и есть суть «галерного» подхода: наперёд договориться как надо и шпарить по ТЗ.
Реальный профессионализм, на мой взгляд, миксовать эти подходы, а не проповедовать какой-то один. Но, глобально, ставка может быть только одна: или культивировать в своей среде самостоятельность и ответственность за результат (и лишь при крайней необходимости пользоваться правом навязать решение), или расшивать коллектив на принимающих решения и исполняющих их. Взамен, иметь однобокость результата и использовать только операционные навыки людей, РЕАЛЬНО не инвестируя в их софт скиллы и игнорируя их общий, кумулятивный опыт.

У обоих подходов есть значительные плюсы и минусы. Оба — честные, по отношению к людям и достойные как бизнес стратегии. Просто, не надо примешивать эджайл культуру ко второму, на мой взгляд. Так и скажите: я раскрасил старый танк в новый горошек, он теперь нарядный! Поехали, постреляем. Впрочем, от эджайл культуры я далёк. Может, неправильно понимаю главные постулаты.

Но я понимаю другое: эти же люди, которые у себя в домах делают ремонты, сосуществуют во всех решениях с тёщами, жёнами и детьми, лечат родителей от раков, эффективно распределяют свои заработанные деньги «чтоб на всё хватило» и всячески иначе способны самостоятельно принимать бизнес решения в рамках своей жизни, в Вашем нарисованном коллективе этого права лишаются и переходят на крик, в котором и логические аргументы — тоже форма крика. И Вас ничего в этом waste не смущает. Почему? У меня только одно предположение, и оно Вам не понравится: потому что девопсы девопсами, эджайл эджйлом, а реального доверия к ним нет и культура брать ответственность за ошибки не наработана.

Мы так не считаем. И ребята в моей команде это уже не раз доказали. По этому, когда девопс Гриша говорит мне, что мой план стул, я отвечаю «а ну, докажи». И, в результате, план модифицируется, или Гриша сдаётся. Как уже бывало.
Такие споры — время. Время — деньги. Компания эти деньги платит. Это, несомненно, инвестиции. Как и любые инвестиции, они не 100% эффективны. У компании довольно хороший финансовый результат. Может, это совпадение. А может, это хороший технический климат?

Так или иначе, CEO компании не считает зазорным во время большого косяка придти к инцидент команде, торчать с нами до глубокой ночи НЕ МЕШАЯ. А потом сказать — «по моему, ребята норм гребут, я доволен», и, со своей стороны, разгрести деньгами перед клиентами то, что мы вынужденно понавытворяли. Можно по разному это воспринимать, но я называю это доверием, и у нас оно в команде есть. У нас много чего нет, но это у нас есть.

Підписатись на коментарі