КДПВ удалена модератором. НЛО предупреждает: применение грубых КДПВ опасно для хабраздоровья.Совпадения случайны, да и вообще это было на другой планете...
Хочу поделиться тремя историями успеха и неуспеха о том, как работается бекенд разработчику в команде с админами.
История первая
Веб студия, количество сотрудников поддается счету одной рукой. Сегодня ты верстальщик, завтра бекендер, послезавтра админ. С одной стороны, можно получить колоссальный опыт. С другой, не хватает компетенции во всех областях. До сих пор помню первый рабочий день, я ещё зеленый, начальник говорит: «Открывай putty», а я не знаю, что это такое. Общение с админами исключено, т.к. ты сам админ. Рассмотрим плюсы и минусы такого положения.
+ Вся власть в твоих руках.
+ Не нужно ни у кого клянчить доступы от сервера.
+ Быстрое время реакции по всем направлениям.
+ Хорошо прокачивает скиллы.
+ Есть полное понимание архитектуры продукта.
— Высокая ответственность.
— Риск поломать продакшен.
— Сложно быть хорошим специалистом во всех областях.
История вторая
Крупная компания, крупный проект. Имеется отдел администрирования с 5-7 сотрудниками и несколько групп разработки. Когда приходишь работать в такую компанию, каждый админ считает, что ты пришел сюда не работать над продуктом, а что-нибудь сломать. Ни подписанное NDA, ни отбор на собеседовании не говорит об обратном. Нет, этот человек пришел сюда своими грязными ручонками испортить наш целованный продакшен. Поэтому с таким человеком нужно минимум общения, накрайняк можно кинуть стикер в ответ. На вопросы об архитектуре проекта не отвечать. Желательно не выдавать доступы пока тимлид не попросит. А когда попросит, выдать с еще меньшими привилегиями чем просили. Практически вся коммуникация с такими админами поглощается черной дырой между отделом разработки и отделом администрирования. Решить вопросы оперативно невозможно. А подойти лично нельзя — админы слишком заняты 24/7. (
- Среднее время деплоя в продакшен 4-5ч
- Максимальное время деплоя в продакшен 9ч
- Для разработчика приложение в продакшене это черный ящик, как и сам сервер продакшена. А сколько их вообще?
- Низкое качество релизов, частые ошибки
- Разработчик не принимает участия в процессе релиза
Ну а что я ждал, конечно на продакшен новеньких не пускают. Ну да ладно, набравшись терпения начинаем получать доверие у окружающих. Но почему-то с админами не всё так просто.
Акт 1. Админ-невидимка
День релиза, разработчик и админ не общаются. У админа нет никаких вопросов. Но почему, понимаешь позже. Админ принципиальная личность, не имеет мессенджеров, номер телефона никому не дает, профиля в соцсетях не имеет. Да даже фото его нигде нет, как ты выглядишь, чувак? Сидим с ответственным менеджером минут 15 в недоумении, пытаемся наладить связь с этим «Вояджер-1», тут на корпоративную почту падает сообщение, что он закончил. Мы что, по почте будем переписываться? А почему бы нет? Удобно, не правда ли? Ну да ладно, остынем. Процесс уже идет, назад дороги нет. Читаем ещё раз сообщение. «Я закончил». А что ты закончил? Где? Куда смотреть, чтоб тебя? Тут вы понимаете, почему 4ч на релиз это нормально. Получаем разработческий шок, но релиз заканчиваем. Желания релизиться больше нет.
Акт 2. Не та версия
Очередной релиз. Понабравшись опыта, мы начинаем формировать списки необходимого софта и библиотек на сервер для админов, с указанием версий для некоторых. Как всегда, получаем слабый радиосигнал, что админ что-то там закончил. Начинается регрессионный тест, который сам по себе занимает около часа. Вроде бы всё работает, но есть один критичный баг. Важная функциональность не работает. Следующие несколько часов танцы с бубнами, гадание на кофейной гуще, детальный пересмотр каждого куска кода. Админ говорит, что всё сделал. Не работает же приложение, написанное криворукими разработчиками, а сервер работает. Какие к нему вопросы. На исходе какого-то часа таки добиваемся от админа, чтобы тот скинул в чат версию библиотеки на продакшен сервере и бинго — она не та, что нужна. Просим админа поставить нужную версию, в ответ получаем, что он этого сделать не может по причине отсутствия этой версии в пакетном менеджере ОС. Тут из закромов памяти менеджер вспоминает, что другой админ уже решал эту проблему, просто собрав нужную версию руками. Но нет, наш этого делать не станет. Регламент запрещает. Карл, мы уже несколько часов сидим, какой регламент?! Получаем очередной шок, релиз кое-как заканчиваем.
Акт 3, короткий
Срочный тикет, на продакшене не работает ключевой функционал у одного из пользователей. Пару часов тыкаем, проверяем. В девелоп среде всё работает. Есть четкое понимание, что неплохо бы заглянуть в логи php-fpm. Системы для логов вроде ELK или Prometheus в ту пору на проекте не было. Заводим тикет на отдел администрирования, чтобы те дали доступ к логам php-fpm на сервер. Тут надо понимать, что доступ просим неспроста, вы же помните про черную дыру и занятость админов 24/7? Если попросить их посмотреть логи самим, то это задача с приоритетом «не в этой жизни». Тикет создан, получаем моментальный ответ от главы отдела администрирования: «Вам не должен быть нужен доступ к логам на продакшене, пишите без багов». Занавес.
Акт 4 и последующие
Собираем ещё не один десяток проблем на продакшене из-за разных версий библиотек, не настроенного по, неподготовленного к нагрузкам сервера и прочих проблем. Кодовые баги, конечно, тоже бывают, не будем во всех грехах винить админов, упомянем только ещё одну типичную операцию для того проекта. Было у нас достаточно много фоновых воркеров, которые запускались через супервизор, а некоторые скрипты надо было добавлять в cron. Иногда эти самые воркеры переставали работать. На сервере очередей молниеносно росла нагрузка, а грусные пользователи смотрели на крутящийся лодер. Для быстрой починки такие воркеры достаточно было просто перезапустить, но опять же сделать это мог только админ. Пока такая элементарная операция выполнялась, мог пройти целый день. Тут, конечно, стоит отметить, что криворукие программисты должны писать воркеры так, чтобы они не падали, но когда они упали, неплохо бы понимать, почему, что иногда невозможно по причине отсутствия доступов на продакшен, конечно же, и, как следствие, отсутствие логов у разработчика.
Преображения
Потерпев это всё довольно длительное время, совместно с командой мы начали рулить в более успешное для нас русло. Если резюмировать, какие перед нами стояли проблемы?
- Отсутствие качественной коммуникации между разработчиками и отделом администрирования
- Админы, оказывается(!), совершенно не понимают, как устроено приложение, какие у него зависимости и как оно работает.
- Разработчики не понимают, как устроена продакшен среда и как следствие не могут эффективно реагировать на проблемы.
- Слишком длительное время занимает процесс деплоя.
- Нестабильные релизы.
Что мы сделали?
К каждому релизу формировали список Release Notes, который включал перечень работ, которые необходимо произвести на сервере для установки очередного релиза. Список содержал несколько секций: работы, которые должен провести администратор, ответственный за релиз и разработчик. Разработчики получили доступ (не root) на все продакшен сервера, что ускорило разработку в целом и решение проблем в частности. Также у разработчиков появилось понимание как устроен продакшен, на какие сервисы поделен, где и сколько стоит реплик. Отчасти стали более понятны боевые нагрузки, что несомненно влияет на качество кода. Общение в процессе релиза происходило в чате одного из мессенджеров. Во-первых, у нас появлялся лог всех действий, во-вторых, общение происходило в более тесной среде. Наличие истории действий не раз позволяло новым сотрудникам быстрее решить проблемы. Парадокс, но это чаще помогало самим админам. Я не возьмусь утверждать точно, но мне кажется, что админы стали больше понимать, как устроен проект, как он написан. Иногда мы даже делились некоторыми деталями друг с другом. Среднее время релиза сократилось до часа. Иногда мы укладывались за 30-40 минут. Количество багов сократилось в разы, если не в десятки раз. Конечно, на сокращение времени релиза влияли и другие факторы, например, такие, как автотесты. После каждого релиза мы стали проводить ретроспективы, чтобы вся команда имела представление, что нового появилось, что изменилось, а что было убрано. К сожалению, админы далеко не всегда на них приходили, ну админы же занятые… Удовлетворенность работой у меня как у разработчика, несомненно, повысилась. Когда ты можешь решить быстро практически любую проблему, которая в твоей зоне компетенции, ты чувствуешь себя на коне. Позже я пойму, что мы в какой-то степени внедрили девопс культуру, не полностью, конечно, но даже то начало трансформации было впечатляющим.
История третья
Стартап. Один админ, небольшой отдел разработчиков. По приходу я полный ноль, т.к. кроме пароля от почты доступов у меня никуда нет. Пишем админу, просим дать доступы. К тому же есть информация, что он в курсе нового сотрудника и необходимости в выдаче логинов/паролей. Дают доступ от репозитория и впн. Зачем давать доступы к wiki, teamcity, rundesk? Бесполезные вещи для человека, которого позвали полностью писать бекенд часть. Лишь со временем получаем доступ к некоторым инструментам. Приход, конечно же, встречен недоверием. Пробую потихоньку прощупать как устроена инфраструктура проекта через чаты и наводящие вопросы. В основном ничего не узнаю. Продакшен такой же черный ящик, как и прежде. Но более того, тут черный ящик даже stage сервера, используемые для тестирования. Кроме деплоя туда ветки из гита мы ничего не можем. Так же мы не можем конфигурировать своё приложение наподобие .env файлов. Доступ для таких операций не положен. Надо заниматься попрашайничеством чтобы тебе поменяли строчку в конфиге твоего приложения на тестовом сервере. (Есть теория, что админам жизненно необходимо чувствовать себя самими важными на проекте, если их не будут просить менять строчки в конфигах, они просто будут не нужны). Ну как всегда, не правда ли удобно?
Такое быстро надоедает, после прямого разговора с админом выясняем, что разработчики родились для того чтобы писать плохой код, по природе своей некомпитентные личности и лучше их держать подальше от продакшена. Но тут ещё и от тестовых серверов на всякий случай. Конфликт быстро набирает обороты. Коммуникации с админом нет. Ситуация усугубляется тем, что он один. Дальше типичная картина. Релиз. Не работает определенный функционал. Долго разбираемся в чем дело, в чат накидываются разные идеи от разработчиков, но админ в такой ситуации как правило исходит, что виноваты разработчики. Потом пишет в чате, стойте я поправил. На просьбы оставить историю после себя с информацией в чем была проблема получаем токсичные отговорки. Мол не суй свой нос куда не надо. Разработчики должны писать код. Ситуация, когда многие телодвижения в проекте проходят через одного единственного человека и только у него есть доступы для совершения нужных всем операций крайне печальна. Такой человек ужасное бутылочное горлышко. Если идеи Devops стремятся сократить time-to-market, то такие люди это злейший враг идей devops'a. К сожалению здесь закрывается занавес.
P.S. Немного пообщавшись на тему разработчики vs админы в чатах с людьми, я встретил людей, которые разделили мою боль. Но также были и те, кто сказал, что с таким не сталкивался. На одной devops конференции я поинтересовался у Антона Исанина (Альфа-банк) как они боролись с проблемой бутылочного горлышка в виде админов, на что он сказал: «Мы их заменили на кнопки». Вот кстати подкаст с его участием. Хочется верить, что хороших админов гораздо больше чем врагов. И да, картинка в начале это реальная переписка.
UPD: Большая благодарность пользователю berez за грамматические корректировки.
Комментарии (39)
alex005
09.05.2019 01:26+1Вообще не понимаю, как можно печатать этот изврат? Чего нибудь дельное печатайте, чтобы конфиги были с пояснениями, репозитории, разные хитрые yml. Заходите сюда смотреть рекламу, как кто-то пукнул в лужу и сказал — я пукнул… Очень мало статей технологического толка. Ну и не нужно говорить — возьми и напиши — у меня нет 150 рублей.
komandakycto Автор
09.05.2019 01:51-2Если по теме сказать нечего, то не обязательно писать много бессмысленных букв.
alex005
09.05.2019 02:35+1По теме нечего говорить, она бытовая, житейская, без самообразования и не стоит времени, потраченного на прочтение — это все равно, что говорить со станочником 6-7-го разряда — в любом случае будешь послан на три.
akdes
10.05.2019 00:41Первую часть комментария понял и поддерживаю.
А 150 рублей тут причём? Честно, не понял — интерестно…alex005
10.05.2019 13:41Да я извиняюсь, может резко написал. Но меня возмутила КДПВ. Честно, статья хорошая жизненная, но это вопрос отношений между людьми и больше психология. Хотелось бы видеть статьи, которые помогают в работе, но их к сожалению мало. На сайте топпрогер мне кажется сейчас больше технически полезных статей. А 150 рублей я имел ввиду, что статью опубликовать — денег стоит.
multiadmin
10.05.2019 14:17На сайте топпрогер мне кажется сейчас больше технически полезных статей.
Имеется в виду tproger.ru или что-то другое?
ppl2scripts
09.05.2019 03:11Доступа в прод вам не дадут во многих местах, в некоторых сертификациях это прямо запрещено. В другие вам не дадут, потому что вы себе глазик выколете. Ну хорошо, не вы, а другие девелоперы, многим из которых ещё очень рано давать рута.
В остальном конечно это всё печально, но непонятно почему вы не требовали хотя-бы схематического ознакомления с инфраструктурой от старших разработчиков, выведения логов куда-нибудь в читаемое место, обустройства себе дев серверов с полным доступом и т.д.
fcoder
09.05.2019 05:32О, эта фигня и в другую сторону замечательно работает.
Во-первых, не стоит недооценивать мощь электронной почты. Я предпочитаю общаться с её помощью, так как её легко переправлять в случае эскалации.
1. Нет доступа в документацию приложения, инфры, в билд-сервер, гит? Отправляем запрос админам. Нет ответа в течение часа? Повторите письмо, укажите что вы из-за них не можете выполнять свою текущую задачу. Укажите в копии своего менеджера (Или того кто фактически выполняет его функции. В стартапе это может быть СТО)
2. Вы не должны хотеть участвовать в деплое в прод и тестировать его после. Это плохая практика в принципе. Вы должны иметь тестовое (точнее пре-прод) окружение, полный дубликат прода, на который вы деплоите сами, используя теже билд-скрипты, что и админы. Это полностью решает проблемы незнания окружения и инфры продакшена, вы не рискуете утечкой/утерей боевых данных, однако вы уверены в деплое. Таким образом мухи отделены от котлет. Если препрод раскатывается из деплой-скрипта и работает, значит проблема не в приложении, а в окружении, за настройку которого ответственны админы.
3. Срочный тикет, баг на проде, требуются детали, например логи. Нет ответа от дежурного админа в течение 15 минут — срочная эскалация до менеджера, в этом случае обязательно продублировать телефонным звонком.
komandakycto Автор
09.05.2019 09:25-3Умом и сердцем мы все понимаем как должно быть. Но тестовым стендом, который является копией боя похвастаться могут не многие. Как и грамотными системами мониторинга, логирования и т.д. Просто все начитались про крутые инструменты, как должно быть, хайп в мире во круг них высокий. А реально используют не многие как мне кажется. Легаси не в смысле кода, а всей инфраструктуры не редкость.
0mogol0
09.05.2019 11:14Как и грамотными системами мониторинга, логирования и т.д.
тут уже как-то обсуждали, что, например, современный мониторинг должен планироваться ещё на этапе разработки, и выполняться в виде эндпойнтов, допускать сложные вызовы для проверки всего потока итп. И это означает, что в разработке сервиса должен принимать участие разработчик системы мониторинга или разработчик сервиса сам должен понимать, что и как должно мониториться, и он должен внедрять соответствующий код для этого.
А по факту, нередко ждут, что код для мониторинга напишет админ, который по привычке может обычно смотреть загрузку аппаратных ресурсов и иногда проверять отдачу сервисом ответа на пинг.
Правда, это уже проблема не отдельных разрабов / админов, а скорее образа мышления менеджеров и архитекторов, которые должны внедрять новые метода в процессы разработки и сопровождения
c_kotik
09.05.2019 06:31+4Жили у бабуси… один админ, другой бекенд. Сказочные
раздоперсонажи в итоге.
vladimirad
09.05.2019 08:21-10По опыту, разработчики хоть не с Венеры, но нечто венерическое в них есть.
0mogol0
09.05.2019 09:01+1Гы… ситуации описаны однобоко, чтобы точно сказать, кто виноват. Хотя в принципе девелоперу на проде делать нечего.
Но бывают и обратные примеры,
Ночь, улица, фонарь, аптека… Прод, документация по деплою, релиз… Не работает, у менеджера истерика, дай девелоперу доступ на прод, пускай он быстро всё поправит. Ок, доступ даётся при условии, что все исправления будут отражены в обновленной инструкции по установке. Починили, всё работает…
Спустя несколько релизов, новый релиз накатывается на новый сервер, опять всё не работает. На истерику релиз-мененджера не реагируем, пускать разработчика отказываемся, теперь он может сидеть рядом и говорить, что проверить на проде. Само собой оказывается, что было несколько изменений параметров системы, которые он «случайно» забыл отразить в инструкции, после их изменения всё работает.
Вот так и жили. Если что, понятно, что не все разработчики такие, есть адекватные, которые готовят нормальную документацию, объясняют, что надо проверять и как.
И кстати, по опыту, чаще именно админы не знают как работает приложение, так как разработчики не снисходят до объяснений к ним. А просто предлагают пользоваться инструкциями типа, здесь кликнуть, а тут нажать ОК. А вот что так сильно меняется в проде, что разраб вдруг вместо знакомого приложения видит black box, мне представить сложно.
Nengchak
09.05.2019 09:08+1Мы поступаем проще. Вот вам окружение, вот вам модули по списку вашему, а если ВАШ апп не поднялся, ну чтож, вот логи, разбирайтесь. И все докеризировано.
komandakycto Автор
09.05.2019 09:29-3Докер это здорово. Но до этого этапа нужно ещё дойти. Тут можно столкнуться с тем, что админ не доверяет сборке написанной разработчиком. Опять же реальная история и об этом прямо говорят.
0mogol0
09.05.2019 10:57+1Тут можно столкнуться с тем, что админ не доверяет сборке написанной разработчиком.
тут должны быть формализированы требования к сборке. Потому что иногда разработчики похожи на инженера, который вместо использования стандартной гайки на 10 или 12, требует, чтобы ему предоставили гайку на 11,3. Например, положены ограничения на доступ, использование портов, а разработчик на это забивает, так как на тестовой машине это ему мешает в отладке.
Ну и опять же вопрос в поддержке продукта. Если за деплой и стабильность работы отвечает разработчик, т.е. он выступает в какой-то мере админом, обычно претензий меньше, чем в ситуации когда ответственность разработчика завершается или серьезно сокращается после запуска в продакшен, а вся ответственность ложиться на админов.
0mogol0
09.05.2019 10:49ну всё это было лет 10-15 назад ;), тогда даже виртуалки только начинали в тестах использовать. И то не для одноразовых тестов, а создали, ручками сконфигурировали, отдали девелоперу, и дальше он на ней месяцами играется.
Сейчас с появлением DevOps, можно просто объединять девелопера и админа в одну команду, отвечающую за разрабатываемый сервис (а иногда и в одно лицо). «Железо» — набор виртуалок / контейнеров, которые как сервис предоставляет другая команда.
axit
09.05.2019 09:21-2Да, с «админским горлышком» бывает боль, работал я как-то в мелкой фирме, сайтики и их раскрутка. В фирме один админ, все сайты клиентов крутились на наших серверах. У админа рождается сын, при родах все проходит не очень гладко и человек уходит на 3 недели, на 3-й день один из серверов падает, шквал звонков от клиентов, директор залетает с вопросом «кто может починить?», «да не вопрос, делов на 5 минут, а доступ есть?», по итогу сервер лежал 4-ре дня. По возвращению админа начались глобальные изменения, началось с замены админа на «кнопочки».
multiadmin
09.05.2019 09:46+1На просьбы оставить историю после себя с информацией в чем была проблема получаем токсичные отговорки. Мол не суй свой нос куда не надо. Разработчики должны писать код.
Синдром вахтера. Можно даже назвать синдромом сисадмина. :-)
Как-то так:
Синдром сисадмина — профессиональная деформация сознания системного администратора, заключающаяся в изменении отношения к другим сотрудникам, повышенным требованиям к их квалификации, проявление авторитарности и излишней категоричности в отношении «чужого» вклада в работу информационных систем по отношении к вкладу «своему».
Сисадмина-вахтёра интересует, в первую очередь, не состояние отдельных задач и качество функционирования системы в целом, а возможность авторитарно судить в пределах той области знания, которую он условно считает «своей». Очень часто им может быть действительно сведущий и грамотный специалист, много потрудившийся в своей области и заслуженно считающий свой вклад исключительно важным. Но нередко случается, что досконально решив какую-либо задачу, сисадмин-вахтёр успокаивается на достигнутом, считая данную тему раз и навсегда исчерпанной. Внесение любых исправлений, даже косметических он считает неприемлемым покушением на его авторитет и компетенцию.
Не пуская никого в «свою» зону ответственности, некогда уважаемый сисадмин погружает систему в состояние стагнации. Особенно трудно приходится новичкам, которые свои первые задачи попробуют передать на ресурсы, управляемые сисадмином-вахтёром. Их ждут проблемы с работоспособностью, бесконечные ожидания, ворох упрёков в непрофессионализме.
Обрекая себя стоять на страже своих ресурсов, сисадмин-вахтёр не развивается дальше, он теряет свои профессиональные навыки, у него формируются стереотипы мышления, он становится менее продуктивным, поскольку вынужден часть своего времени тратить на защиту подчиненных ему ресурсов от любого чужого вмешательства.
P.S. Текст создан на основе этой статьи. :-)
andreysl
09.05.2019 12:13+1В мою бытность админом все разногласия с разработчиками решались за совместным распитием пива по пятницам
Tzimie
09.05.2019 14:16-2Единственное что здесь верно, админы действительно часто отвечают токсично. Я, кстати, админ
NishchebrodKolya2
09.05.2019 14:28-6Сисадминами становится те кто не смог в программировании, отсюда все комплексы.
saburovga
10.05.2019 22:39Как минимум в моем случае — это не так. Я стал сисадмином, потому что программирование мне кажется скучным.
akdes
09.05.2019 15:20+3Один я горю интересом увидеть эту страшную КДПВ, которую я упустил… и ищу её в комментариях?!
eugene_bx
09.05.2019 18:22+1Теперь напишите статью про то как вам хорошо жилось с хорошими админами, ну а если таких не было, то может быть надо переосмыслить свою позицию.
Хотя конечно очень помогает некоторое время поработать админом / в поддержке приложений, взгляд с другой стороны многое проясняет.
komandakycto Автор
10.05.2019 23:01Страсти утихли, можно резюмировать. Ни минуты не сомневался, что за эту статью сольют карму. И ни минуты не пожалел, что опубликовал её. Даже отпустило «больное место» как-то. Про картинку были сомнения, я понимал, что её удалят, но по скольку переписка на ней была реальной и не содержала мата я рискнул. Её содержимое олицетворяло суть статьи.
Некоторые писали, что если бы у вас был docker, система мониторинга, инфраструктурная схема, дев сервера копирующие продакшен, то жизнь была бы прекрасна. Наверное да, но вот представьте ничего этого не было. А работать нужно было. Я уверен таких компаний много, просто про плохую инфраструктуру не принято писать статьи и рассказывать на конференциях.
В целом токсичность комментариев стремится к уровню токсичности админов из этой статьи. Практически никто не поделился личным опытом, я предложил тему и ожидаю комментарии по теме, а в большинстве своем комментарии сущий мусор, который видимо нацелен на оскорбление автора, принижение.
Я не понимаю, народ неистово минусует за вполне конкретный вопрос комментатору про КДПВ. Или например товарищ alex005 практически с ходу выливает тазик с грязью, ничего не ответив по теме, а колизей в этом время аплодирует стоя. Это дурные гены в обществе, другого объяснения нет.
P.S. Тем кто понял проблему, спасибо за внимание.
Taciturn
10.05.2019 23:31Я не понимаю, народ неистово минусует за вполне конкретный вопрос комментатору про КДПВ.
Это вопрос является демонстрацией терминальной стадии даже не лени, а какой-то странной инфантильности. Gooogle, Яндекс, Bing, DuckDuckGo — везде по запросу «КДПВ» сразу же находится определение.multiadmin
11.05.2019 07:27Это вопрос является демонстрацией терминальной стадии даже не лени, а какой-то странной инфантильности
Мне кажется, что «демонстрацией терминальной стадии даже не лени а какой-то странной инфантильности» является минусование безобидного комментария.
Хорошо, что нашелся адекватный человек и просто ответил на этот простой вопрос.
А люди, которые не сливают бездарно свое личное время в интернете в большом количестве, а занимаются делом, могут и не знать, что такое «КДПВ».Taciturn
11.05.2019 12:49Так потому и нет у этих людей времени, что вместо того чтобы за несколько секунд узнать ответ из поисковых систем, они тратят куда больше своего и чужого времени на то, чтобы спрашивать у людей.
megahertz
С контейнерами все стало гораздо проще.
PS. По-моему, вы погорячились с КДПВ. Все-таки на хабре такие лучше под кат и возможно спойлер.
komandakycto Автор
Что такое КДПВ?
megahertz
Картинка Для Привлечения Внимания