В эпоху облаков настройка Linux-сервера своими руками кажется неким вымирающим искусством. Для непосвящённого человека даже bash-скрипты выглядят как заклинания, а коллеги проникаются уважением к сисадмину, как древние индейцы к своему шаману…
Сейчас это «древнее искусство» вновь стало актуальным. История идёт по кругу — всё старое возвращается в новом виде. Запуск сервера на своём хостинге стал хорошей альтернативой облакам. Этому есть ряд причин, которые мы не будем подробно разбирать, только повторим вкратце: безопасность, свобода, контроль над своими данными, экономия финансов.
▍ Старое или новое. Контроль или зависимость
Выбор активного управления своей инфраструктурой (on-prem, VPS, штатные сисадмины) — часть более широкой дискуссии, как правильно выбирать инструменты и технологии. Эта дискуссия обширна и ведётся по многим направлениям. В общем, это скорее философский вопрос выбора между старым и новым. Между скучным и интересным. Для важных задач люди склонны выбирать всё-таки скучные, проверенные и надёжные технологии. Даже существует вероятность, что они менее эффективные и/или менее удобные.
Например, если нужно выбрать оптимальный инструмент для решения каждой конкретной проблемы, то в теории это складывается следующим образом:
Но на практике реальный выбор выглядит иначе:
Это жизнь. При выборе мы учитываем не только технические факторы.
Старое/новое — это первое измерение в многомерном пространстве выбора.
Вторая ось — управляемые/неуправляемые службы. В одном случае мы самостоятельно всё контролируем, а в другом полностью отдаёмся во власть облачной платформы BaaS/PaaS, которая предоставляет полный комплекс услуг. Между этими двумя крайностями есть разные варианты компромиссов вроде управляемых облачных сервисов типа Amazon RDS.
Последнее десятилетие развития IT-индустрии можно смело назвать эпохой облачных сервисов, когда все дружным строем направились в AWS, GCP и Azure. Каждая компания думала, что чем меньше она управляет своей инфраструктурой — тем лучше. Сэкономить на железе, уволить всех инженеров и просто зарабатывать денежки.
Но сейчас выясняется, что не всё так просто. И ситуация начинает понемногу меняться в сторону более компромиссных решений — частично управляемых сервисов с инженерами в штате.
По мере усложнения (и удорожания) облачных платформ мы вдруг вспомнили, что ещё 10−15 лет назад даже очень маленькая компания могла поднять высоконагруженный сервис на собственных серверах. Вплоть до того, что это мог сделать один человек, единственный сисадмин, как Марко Армент (на фото справа), который в одиночку написал и запустил сайт Tumblr в районе 2007 г. (спустя шесть лет продан Yahoo за $1,1 млрд). И начинаешь задумываться: а к добру ли все эти облачные изменения? Марко пишет, что при большом желании такой сервис можно запустить «дёшево, просто и разумно», если подойти к делу с умом. Поскольку у него не было времени на обслуживание серверов, то он изначально настроил их так, чтобы они не требовали особого администрирования. Выбор Марко Армента в 2005 году: дистрибутив CentOS (по сути, бесплатная версия Red Hat Enterprise Linux), который удовлетворяет трём основным требованиям:
-
очень стабильный (консервативный), чтобы не было частых обновлений, которые могут всё сломать;
-
медленно развивающийся, чтобы не приходилось переучивать основы ОС и осваивать новые инструменты;
- популярный, так что по любому вопросу в интернете куча инструкций.
Он говорит, что Debian тоже неплохой вариант.
Из других сайтов на собственном хостинге с миллионной аудиторией и минимальным обслуживанием (1−2 человека) можно посмотреть на архитектуру Stack Overflow. Вспоминается также пример WhatsApp, когда штат компании составлял 50 человек, а аудитория превысила 200 млн пользователей. Изначально российский программист Игорь Соломенников с фриланс-биржи RentACoder.com написал это приложение в одиночку по заказу основателей WhatsApp, не умевших хорошо программировать. К сожалению, Игоря так и не взяли в число совладельцев компании, которую спустя пять лет продали за $19 млрд.
На самом деле таких примеров много. Главный принцип у этих компаний: свой хостинг по умолчанию и настройка высоконагруженных серверов таким образом, чтобы они требовали минимального администрирования и поддержки.
▍ Сисадмины превратились в девопсов
Повсеместный переход в облако — это объективный факт. О причинах можно долго рассуждать: распространение философии «быстрой разработки с частыми апдейтами», маркетинговые бюджеты техногигантов, пропаганда из технологических СМИ. Истина, как всегда, где-то посередине. Облачные сервисы и контейнеры — это великие достижения в IT, их нужно использовать, но и не забывать про собственные серверы, ведь только на них можно построить по-настоящему высоконагруженный сервис дёшево и эффективно.
Администрирование Linux-сервера — это, конечно, вымирающее искусство, но одновременно и всё более востребованная профессия. Bash-программирование востребовано даже в веб-разработке. Bash-скрипты могут сделать абсолютно всё: и сгенерировать сайт (тем более в связке с ChatGPT), и поднять веб-сервер.
Распределение языков программирования в нормальном веб-приложении, источник
Для сравнения: разработка современного веб-сайта с модными технологиями выглядит как совершенное безумие:
В наше время у сисадминов, девопсов, да и вообще у всех программистов добавился ещё один опциональный навык — работа с ChatGPT, то есть грамотное конструирование запросов (промтов). Есть маленькие хитрости, какие слова добавлять к запросу, чтобы ответ был более точным и информативным, когда вы просите составить bash-скрипт или сгенерировать настройки конфигурации. В принципе, работодатели ещё не требуют от этих знаний в обязательном порядке, но для самих специалистов полезно освоить новые инструменты. Для собственного удобства, чтобы экономить время. Только надо проверять всё, что выдаёт эта система. Но ChatGPT реально удивляет, подсказывая такие варианты синтаксиса Bash, о которых вы даже не знали, например, расширение параметра с вложенными скобками и др. Таким образом, ChatGPT может выполнять роль инструктора и учителя в чём-то…
В общем, от современного сисадмина (девопса) требуют разбираться ещё много в чём: и во всех продуктах Amazon (а их около сотни, причём список постоянно меняется), и в других облачных сервисах, уметь немного программировать, да ещё следить за всеми новинками в IT.
▍ Потеря компетенций
Переход в облако и увольнение сисадминов — это необратимая потеря компетенций, специалистов и технологическая деградация. Кроме того, потом возникает проблема вернуться на свой хостинг (on-prem). Это так называемая «облачная репатриация»: во многих случаях получается, что переход в облако — необратимое действие. Практически никогда его потом не получится «откатить». По двум причинам:
- привязка к поставщику;
- потеря компетенций.
Если вы поднимаете систему на своём сервере on-prem или на VPS, то в любой момент можете перейти на другое железо или к другому хостеру. В случае облачных сервисов это нетривиальная и не всегда возможная процедура, потому что у некоторых вендоров есть уникальные и проприетарные сервисы (типа AWS Lambda), которые так просто не экспортируются. Это и есть привязка к поставщику.
С потерей компетенций всё понятно — если опытный сисадмин работал в вашей компании много лет и всё знал как свои пять пальцев, то после его увольнения второго такого вы не найдёте никогда. Просто потому, что опыта работы в вашей компании нет ни у одного специалиста на рынке труда. Придётся обучать новичка с нуля, а кто это будет делать?
Вот и получается, что переход в облако становится необратимым. Поэтому и популярны инструменты вроде Cockpit, чтобы управлять сервером VPS мог даже новичок из-под Windows, который не знает даже консоль. Но это суррогаты.
Cockpit: графический веб-интерфейс для управления сервером
▍ Базовые знания
Очень жаль, что настройка и управление Linux-сервером на своём собственном железе/хостинге становится вымирающим видом искусства. На самом деле это крайне полезный профессиональный скилл. Основы администрирования Linux и огромная библиотека софта для установки на своём сервере — одна из самых полезных вещей, которые может освоить девопс и разработчик, особенно в начале карьеры. Эти знания открывают целый новый мир возможностей. Они дают понимание, как всё работает на самом деле, как использовать железо с максимальной эффективностью.
Для освоения и закрепления базовых навыков можно рекомендовать следующие ресурсы:
- Книга «Эффективная консоль»
-
Руководство по безопасности Linux-сервера
-
Упражнения для девопсов (сейчас 2624 упражнений и вопросов). Наверное, полезно также при подготовке к собеседованиям
- Управление Linux, подборка репозиториев на Github
Управление Linux-сервером — это базовый навык, который останется актуальным спустя годы и десятилетия. Скорее всего, на протяжении всей вашей карьеры. Bash, SSH, nginx/Apache и даже сам Linux — ничто из этого не устареет в обозримом будущем. Подумайте, что ещё такого долговечного есть в IT-индустрии? Чем раньше освоить эти инструменты — тем лучше.
Даже в домашнем хозяйстве навыки системного администрирования сэкономят десятки или сотни долларов в месяц, потому что вы своими силами можете поднять инфраструктуру, за которую облачные компании берут ежемесячную плату. Те же системы видеонаблюдения, стриминговые сервисы, медиасерверы, NAS (самодельный вместо фирменного), системы резервного копирования, умный дом и многое другое. А сотня сэкономленных долларов в месяц — это уже $52 093 за двадцать лет (с капитализацией 7% годовых) или $75 937 (с капитализацией 10%). Про $200 в месяц и говорить нечего, там цифры астрономические…
Такова ценность базовых навыков управления Linux-сервером в домашнем хозяйстве.
Выходит, что изучение Linux — одна из самых эффективных инвестиций в жизни человека. Вы получаете от $50 000 до $75 000, потратив всего несколько месяцев, причём это обучение приносит ещё и огромное удовольствие. Ведь программирование — как зависимость, организм получает кайф и требует повышения дозы.
А что касается развития всей индустрии, то после массового перехода в облака некоторые компании вдруг обнаружили, что простая серверная стойка может быть в несколько раз дешевле, чем облачное обслуживание. И они возвращаются обратно: к серверным комнатам в конце офисного коридора (или у хостера).
Узнавайте о новых акциях и промокодах первыми из нашего Telegram-канала ????
Комментарии (85)
nApoBo3
23.10.2023 09:29+6Странно рассуждение про рост потребности в bash "программистах". По мне так все ровно на оборот и bash вытесняется другими языками, например python, которые успешно заменяют bash при этом являются языками общего назначения.
Pas
23.10.2023 09:29+11Ни разу не видел полной замены shell-скриптинга (это не только BASH) питоном или чем-то ещё. Как дополнение — ок, но как замену — нет. Ну и вообще, нормальный сисадмин может и в питон постучать и shell-скрипт разобрать или быстро накидать, и понять, "почему этот чёртов Makefile не работает", а также YAML, HCL, J2 и прочие выпендрёжи, которые неизбежно встречаются в современном зоопарке.
nApoBo3
23.10.2023 09:29Вы как давно разбирались с makefile который неизбежно встречается. Лично я последний раз лет 15 назад. Я понимаю, что некоторые и ядра свои собирают, но это не "неизбежно встречаются в современно зоопарке". В современно зоопарке AWS, кубер, разные эластиксы и папеты, а не makefile.
saboteur_kiev
23.10.2023 09:29Как скопировать директорию на питоне?
outlingo
23.10.2023 09:29+16os.exec("cp -R /path/to/directory /new/dispoition") !!!
saboteur_kiev
23.10.2023 09:29а зачем питон, если из него вызывать шелл =)
nApoBo3
23.10.2023 09:29если утилита не имеет иных механизмов взаимодействия в силу исторических причины ее нужно по религиозным соображения переписать в виде библиотеки или пакета? Зачем если в языке предусмотрен механизм подключения и такого рода утилит через exec? Если так принципиально использование "чистого" питона без внешней утилиты есть os и shutil.
saboteur_kiev
23.10.2023 09:29+1Если на шелле это будет
cp -R /path/to/directory /new/dispoitionто зачем нужен питон, где будет
os.exec("cp -R /path/to/directory /new/dispoition") !!!И я думаю, что кроме os.exec вам еще импорт надо указать.
Ndochp
23.10.2023 09:29Затем, чтобы (не знаю я линкуса, извините) вместо
FOR /f "tokens=1-7 delims=/-:., " %%a IN ("%DATE: =0% %TIME: =0%") do ( SET NewBk=.\Docs_Sample_%%c.%%b.%%a_%%d.%%e.%%f.%%g.dt )Написать
Дата = ТекущаяДата(); ИмяФайла = ".\Docs_Sample_" + Формат(Дата, "dd.MM.yyyy_hh.mm")+".dt";И потом вызвать команду системы. Точнее в данном случае даже приложение в пакетном режиме. Причем на втором языке я пишу все время и так, а первый вариант - чистое SO-дривен, так как ну нафига мне часто продвинутые возможности батников?
khajiit
23.10.2023 09:29+1Для линукса это не так очевидно, ибо там будет что-то вроде
declare -A BASES="<bases list>" for B in $BASES; do <backup utility name> <options> -o "<backup folder>/$B_`date +%F%T`.dt"; doneПри этом и BASES тоже можно заполнить скриптом, и сложить это все в отчет, и дернуть sendmail в конце
khajiit
23.10.2023 09:29Использовать xonsh?
helg1978
23.10.2023 09:29+3В статье зачем-то много раз повторяется мантра про "администрирование севера это вымирающее искуство", как будто автор хочет заставить нас в это поверить с помощью НЛП.
Камон, в мире очень много легаси проектов, которые долго еще будут использовать дедики и виртуалки. Да и сам Амазон иногда говорит, что "для этого облачного севриса вам нужно развернуть EC2 инстанс", и хоть он и развернется из шаблона, но все же это уже живой сервер, в который кто-то должен уметь зайти глянуть почему что-то не работает.
Ну и армия девопсов вроде не уменьшается, неужели все станут клик-опсами?
Andruh
23.10.2023 09:29+3А я так и не успел понять зачем облака: там всё сложно, хитро, неэффективно. Сейчас вот пришёл чувак и объяснил: всё нормально, так всё и есть. Осталось дождаться следующего, который скажет: так всегда и было.
M_AJ
23.10.2023 09:29+7А я так и не успел понять зачем облака
Если без DevOps практик, то чтобы не заботиться о железе. Или для разовых задач/тестов когда нужно например обучить нейросеть, а покупать навсегда кучу видеоускорителей, что бы воспользоваться ими один раз -- нецелесообразно.
С девопс практиками сфера применения расширяется: можно например автоматически масштабироваться в зависимости от нагрузки, что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными, а пользователи при этом не будут жаловаться, что ваша онлайн игра легла прямо в долгожданный новогодний ивент. Можно обновляться без простоя, можно плавно перестраивать архитектуру разворачивая временные схемы и уничтожая их, когда они стали ненужными и так далее. В общем те же плюсы, из-за которых люди в принципе используют аутсорс или аренду.
olku
23.10.2023 09:29+1Специализация, сертификация, безопасность, замена capex на opex, экспорт многих рисков... Да много чего, и это не бесплатно. Поэтому свою железку и облако сравнивать лишь бухгалтерским способом не вполне корректно.
Ru6aKa
23.10.2023 09:29+3Все с точностью до наоборот. Без DevOps лезть в облака финансово опасно, там столько подводных камней, которые просто приведут к сжиганию кучи бабла.
Пример с нейросеткой - это прям очень сильно узкая ниша, и которая появилась сильно позже облаков и всей этой облачной истерии.
можно например автоматически масштабироваться в зависимости от нагрузки
Ага, только это все маркетинговый bullshit, как только дело до этого доходит, то получаем попу, разного размера. Начиная от того что cpu/memory usage метрики не годятся для не cpu/memory bound задач - а веб как раз и не является такими задачами.
что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными
Ага, только на практике ты вряд ли нормально настроишь лимиты, поэтому тот же гугл пытается использовать ИИ для управления ресурсами, и клиентам предлагает autopilot для решения этой задачи. Но получаеться не очень, все тоже сжигание бабла, потому как поднимает лимиты на любой чих, а вот понижать уже сам не будет. Вызвал клиент раз в месяц эндпоинт для генерации тяжелого отчета - лимиты поднялись, и все с этого момента платишь за ресурсы по новым лимитам. Если без автопилота с жесткими лимитами, то у тебя просто перегрузиться контейнер, и по F5 клиент пойдет перегружать соседний контейнер - отчет то он хочет получить.
Можно обновляться без простоя, можно плавно перестраивать архитектуру разворачивая временные схемы и уничтожая их, когда они стали ненужными и так далее.
Это все можно получить и без облаков.
И при всех плюсах у облаков достаточно минусов. И нужно прям сильно хорошо понимать зачем и почему нужно облако для запуска нагрузки в нем.
Pas
23.10.2023 09:29+1А ещё хочется добавить, что облака, в особенности публичные, это перепродажа того же самого железа, только за куда более существенные деньги. В облаках зашито много маркетинга и надо это понимать. Не стоит забывать, что облачным провайдерам очень выгодно пушить многие популярные нынче практики, раздувающие использование сервисов просто в разы.
M_AJ
23.10.2023 09:29Пример с нейросеткой - это прям очень сильно узкая ниша, и которая появилась сильно позже облаков и всей этой облачной истерии.
Пример с нейросеткой выбран просто как самый наглядный и понятный, сама сфера GPGPU гораздо шире и появилась тоже не вчера.
Начиная от того что cpu/memory usage метрики не годятся для не cpu/memory bound задач
Но ведь вы можете пользоваться теми метриками, которые посчитаете нужными. А вэб он разный, сейчас чего только не делают в вэбе, да и далеко не все сервера в интернете это именно вэб.
Это все можно получить и без облаков.
Конечно можно, только если вам для этого нужны дополнительные мощности на время, например чтобы поднять что-то параллельно, то не всегда имеет смысл покупать необходимое для временных задач железо навсегда. Опять же, смотря что считать облаками. Кто-то понимает этот термин более узко, а кто-то более широко, с моей точки зрения, если это VPS, а не колокейшн или арендованый дедик в датацентре, то это уже облака, а кто-то под этим понимает только PaaS.
Само собой, что облака это инструмент, которым нужно пользоваться, если он подходит для вашей задачи. Странно арендовать экскаватор, если вы хотите выкопать яму 2х2х1, но отказываться от использования экскаватора при выкапывании котлована, потому что при желании это можно сделать и лопатой -- не менее странно.
PrinceKorwin
23.10.2023 09:29Я бы ещё добавил, что облака дают территориальную независимость.
Например - находясь в Азии можно поднять сервер в облаке в США чтобы максимально уменьшить пинг для своих клиентов.
select26
23.10.2023 09:29+2можно например автоматически масштабироваться в зависимости от нагрузки, что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными,
Можно конечно. Только все чаще оказывается что ДЕШЕВЛЕ купить эти сервера, даже с учетом того, что они будут задействованы только на 10%.
Моя компания переезжает из облаков в on-prem. Экономический эффект - миллионы долларов в год.
Посчитали, что сравнимую конфигурацию в железе нам дешевле содержать в 5 раз, чем в облаке! И это не смотря на лихие корпоративные скидки. Экономисты считали: с аммортизацией, поддержкой и т.п.
А тяжелые ноды для кэшей (терабайты RAM и NVMe) - там экономия еще больше.
В облаках тоже не альтруисты собственники - они тоже считают неплохо.Оптимальная конфигурация при переменной нагрузке: мин. загружать на on-prem, а спайки докупать в облаке.
M_AJ
23.10.2023 09:29Только все чаще оказывается что ДЕШЕВЛЕ купить эти сервера, даже с учетом того, что они будут задействованы только на 10%.
Понятно, что это все индивидуально. Кому-то может быть дешевле и выгоднее даже свой ДЦ построить, вместо того чтобы где-то размещаться, но это не значит, что это выгоднее всем и всегда. Я не думаю, что в какой-нибудь Wargaming никто не умеет считать, и поэтому они пользуются AWS а не ушли в on-prem, и что у других клиентов AWS такая же история, и там тоже никто не умеет считать.
lightman
23.10.2023 09:29что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными, а пользователи при этом не будут жаловаться, что ваша онлайн игра легла прямо в долгожданный новогодний ивент.
А почему многие конторы, даже мастодонты вроде Blizzard об этом не знают? И по сей день мы нередко видим, как на крупных релизах лагают и ложатся сервера. Или может у этих компаний не хватает денег арендовать достаточно мощностей?
garwall
23.10.2023 09:29ну в случае близзард, и прочих игрушек, как мне кажется, важнее не получить по cap-теореме сплит-брейна за счет сниженного availability
lightman
23.10.2023 09:29+1по cap-теореме сплит-брейна за счет сниженного availability
Извините, а можно по-русски для тех, кто не в теме управленческих нюансов?
khajiit
23.10.2023 09:29+1А кто сказал, что их не устраивают ажиотаж и очереди после выхода очередного дополнения?
lightman
23.10.2023 09:29Отвечу вопросом на вопрос: а разве очереди и отрицательные отзывы об игре это желанная ситуация для компаний? И не очередями едиными: бывают ошибки, вылеты, лаги. Что в этом хорошего?
khajiit
23.10.2023 09:29Видимо, профит от ажиотажа оценивается большим, чем потери на некоторый процент плохих отзывов, только и всего.
BlackSCORPION
23.10.2023 09:29Сложно и хитро да, насчёт неэффективно это вопрос. Облака это сервис, для чего то они подходят лучше но не решают всех проблем на свете. Я например личные сайты, размещаю на aws и это не стоит мне почти ничего (меньше доллара в месяц)
Сайт раздаётся с s3 (файловое хранилище) через cloudfront (cdn), ssl сертификат от certificate manager, сам ротируется, бэкенд на api gateway + lambda + dynamodb.
saboteur_kiev
23.10.2023 09:29+6Но ChatGPT реально удивляет, подсказывая такие варианты синтаксиса Bash, о которых вы даже не знали, например, расширение параметра с вложенными скобками др
Это же базовый функционал.
То, что программисты, которые никогда не изучали баш, и считают его недоязыком, внезапно открывают для себя, что в bash есть довольно много разных интересных встроенных возможностей, не значит что chatGTP говорит больше, чем документация.
Xambey97
23.10.2023 09:29+3Не знаю как у девопсов, но у разработчиков сейчас такие тенденции, что работодатели очень сильно хотят экономить на первых и скидывать их работу на вторых, не отменяя работы последних для KPI. Я не так давно ушел из одного весьма не бедного банка из первой десятки, потому что выгорел с этой херни до состояния "видеть работу не могу, хочу спать больше 4х часов", занимаясь наладкой инфраструктуры, пытаясь выбить ресурсы неделями, экспериментировать с конфигурациями и чуть ли не все свое свободное время после работы и во время работы это вот, т.к я достаточно ответственный человек... ну а топ админы говорили набрав в рот воды, что "ваша команда админит полностью ваш тенант, у нас туда доступов нет, ни к сервисам, ни к раннерам, никуда, еб***** сами (с) ваши инженеры по инфраструктуре". Занимался этим 3 месяца, почти не делая своей профильной работой на проекте вообще, где я силен, а задачи то 'висят'. Получилось так себе, не хочу больше работать с этим всем далее как "создать конфиг сервиса по шаблону/докам" и тем более с кучей кастомных инструментов by devops, у которых, как правило, нет документации, и ты сидишь и редеплоишь сутками * конфиги, читаешь исходники утилит, чтобы понять что они делают и как все это работает вместо девопсов... и тебе на каждом дейлике стремно говорить о том, что ни черта не получается... Не в жизнь больше не буду работать там, где на меня такое повесят эффективные манагеры...
alexkuzko
23.10.2023 09:29+3Отличный пример, описанный фразой "кроилово приводит к попадалову" ©
В вашем случае потерян разработчик. Кстати, теперь то понятно почему админы ненавидят принтеры? :)
vvbob
23.10.2023 09:29+3Без обид - но это ваш личный косяк. Вы позволили совоменеджерам сесть себе на шею, что они обычно с великой охотой проделывают, как только находят подходящую жертву. Надо четко понимать границы своих компетенций и не лезть не в свою область, если вы, конечно, не собираетесь мигрировать в другую специальность, но из вашего поста я понял что не собирались.
Я бы вот в ответ на "еб***** сами" просто скинул эту проблему на менеджмент проекта, и пускай они там с топадминами сами разбирались, это их работа, им за это зарплату (весьма нехреновую) платят, а сам бы занимался своими задачами, в которые я умею и разбираюсь.
Xambey97
23.10.2023 09:29+2Да, во многом вы правы. Началось то все с благодати, я наконец-то смог освободить время под развитие процессов на проекте, предложил менеджеру и ребятам перейти на TBD, что мы сделали, развитие поперло, скорость фич на коротком горизонте, хотел развернуть готовый бек и фронт для работы с фича тоглами (Unleash)... чтобы бекенд еще наш интегрировать с тоглами, лекции для тестировщиков по работе записал, библиотеку для работы с фронтов с ним написал. И понеслась... То критические баги в этом готовом решении, то херня с инфраструктурой, то отсутствие доступов. Постоянная долбежка архитектору, который единственный и имеет доступы ко всему в тенанте (к нему предъяв никаких, он тоже не знал че делать), девопсам и админам, всех доступных уровней с попыткой понять, что я не так делаю, запрос ресурсов для тенанта..., и отговорки про то, что это не наша зона компетенций (и это правда так, потому что команды отдалили от тех. поддержки максимально)... В результате сел сам разбираться, но тяжело шло, а больше всего времени тратил на бесконечные редеплои конфигурации, пытаясь угадать, что не так... И так вот до конца. По итогу решил все проблемы, но ресурсов не было чтобы развернуть, и тут я уже так сгорел, что толком не смог нормально продолжать работать. До сих пор отойти не могу никак с этой дичи, сплю урывками по 4 часа без работы, даже не пытаюсь устраиваться, благо есть возможность, а уже 2.5 месяца прошло почти, подумываю уже мб пора сходить к неврологу за таблетками...
vvbob
23.10.2023 09:29Эх.. сочувствую, жиза, все эти банки, да и вообще всякие крупные корпорации так забюрократизированы, что больше борешься с системой, чем с какими-то профессиональными задачами. Я по этой причине с одного банка так уволился, достало биться башкой о стену, когда каждый чих сопровождается сбором десятка согласований. Девять кое-как выдерешь, на десятом на какого-либо начальника шлагбаума нарвешься, который не дает добро просто потому что..
kreativf
23.10.2023 09:29Звучит знакомо. Цитата инженеров по инфраструктуре даже имеет смысл, если они действительно занимаются инфрой, а не девопсом.
vaniacer
23.10.2023 09:29+2...Bash-скрипты могут сделать абсолютно всё: и сгенерировать сайт...
И в игру поиграть piu-piu, и утилиту для ssh сделать sshto и для модного кубера kube-dialog...
Творите, выдумывайте, пробуйте!)
Dominux
23.10.2023 09:29-2Сисадмины, которые разве что умели лишь следить за тем, чтобы приложение и база не упали, да порты нужные открывать/закрывать. Они едва ли знали, что и зачем нужно
То ли дело девопсы... и приложение тебе соберут, и выкатят всю эту гигантскую инфру микросервисов и прочей ерунды. И так же, проследят, чтобы поды не упали да порты прокинут нужные
Мб автор не шарит за девопс, особенно в бигтехе. Или за приложения, кроме тех, что с одним интансом приложения и одним интансом бд
Lazhu
23.10.2023 09:29+1Мб автор не шарит за девопс
Вчерашние эникеи, сегодня переливающие джейсоны из пустого в порожнее
dmitrii-bu
23.10.2023 09:29Администрирование Linux серверов и решение проблем с производительностью инфраструктуры, скалирование системы на более высокие нагрузки, отказоустойчивостью и и тд безусловно вызывают интерес, только вот к работе программиста, особенно в крупных компаниях, это почти не имеет отношения и подобными вещами занимаются SRE/DevOps инженеры.
Ведь программирование — как зависимость, организм получает кайф и требует повышения дозы.
По опыту работы в крупном Энтерпрайзе РФ и зарубежом, работа программиста сейчас даже на уровне Senior это копипаст кода по шаблону и бесконечная война в комментариях кодревью из-за условной скобки, поставленной не на той сторке (к сожалению, по опыту трех разных компаний за крайние 4 года, 99% комментариев к ревью именно такие). Посмотрев на все это я перешел в девопсы и ниразу не жалею.
SneakyJoe
23.10.2023 09:29+1Таким образом, ChatGPT может выполнять роль инструктора и учителя в чём-то…
Я джун SRE, использую иишки (не только chatgpt) чтобы исследовать варианты работы с неизвестными мне областями профессии чтобы не тыкать старшего постоянно и не заставлять его меня бейбиситить. Вывод ии можно проверить или переработать под актуальный тип работы, и они показывают иногда штуки и связи о которых мой джунский мозг даже не догадывался.
fieldof
23.10.2023 09:29И начинаешь задумываться: а к добру ли все эти облачные изменения?
Так цель владельцев облаков замкнуть рынок на себя и монополизировать рынок, предварительно смазав медом. Кому-то разнообразие доступных решений к добру, а кому-то вообще ни разу нет.
Minashvili_George
23.10.2023 09:29Отличная статья, согласен с главной мыслю публикации.
Работаю Linux Админом, разрабатываю код на Ruby и Puppet DSL для инфраструктуры.
Считаю что все зависит от бизнес модели вашей компании от неё в большей степени отталкивается логика приложения а дальше Разработчики с Админами придумывают как с этим жить.
Если у вас Облака то надо постоянно искать где ужаться, меньше логов от приложения сохранять, измерять скорость CI, наблюдать все что тратит денежку, следить за законами какие данные можно хранить в Облаке какие нет, сами Приложения тоже должны уметь расширяться, скалироваться, шардироваться и так далее, также нужно следить за инфляцией, повышением тарифов, отслеживанием ресурсов, подсчетом этих ресурсов, изучением и сравнением других облаков.
Если у вас свои сервера то фокус идет на закуп, инвентаризацию, автоматизацию, возможность безопасных, повторяймых конфигураций, придумывание процессов для снижение различий в настройках серверов, создание определенных возможностей которые требует именно ваша инфраструктура, документировании своих решений, в итоге сами себе облачный провайдер
Сильным вариантом будет гибридный ландшафт, пара публичных облаков и свое внутренее облочко))
а тут нас ждут все достоинства и недостатки разом
И как пишет автор
Уметь настроить linux в такой ситуации это действительно одно из выгодных вложение =)
M_AJ
Как будто самое главное в построении отказоустойчивой системы это выбрать ОС. Если мы хотим по-настоящему отказоустойчивую систему, то нам нужен кластер, для нормального кластера нам нужны стэкируемые коммутаторы, две или больше отдельных физических линии от провайдера, правильно настроенные роутеры, какой-нибудь Ceph или GlusterFS, бэкапы. Выбор дистрибутива тут пожалуй наименьшая из "проблем".
Только если до этого ты платил за облака, если не платил, то ничего и не сэкономишь.
Главное не забывать, что от "передоза" можно и выгореть. Это даже если отбросить тот "малозначительный" момент, что эксплуатация это не программирование.
Airtrain
>то нам нужен кластер, для нормального кластера нам нужны стэкируемые коммутаторы, две или больше отдельных физических линии от провайдера, правильно настроенные роутеры, какой-нибудь Ceph или GlusterFS
Вы как будто про СУБД не слышали, даже реляционные, нынче все масштабируются без вышеописанного. А уж nosql и подавно. В двух разных ЦОДах VDSы взял и в шоколаде.
>$50 000 до $75 000
да, да, за несколько месяцев опыта.. У меня и с 20 годами даже близко не столько.
alan008
>> нынче все масштабируются без вышеописанного
Какие все? SQL или noSQL ? И что вы подразумеваете под масштабированием. Горизонатальное масштабирование (шардирование) с синхронизацией транзакций в шардах умеют далеко не все, а точнее сказать почти никто и не умеет. Умеет YDB разве что. А многие ли ей пользуются снаружи Яндекса?
Как же бесят такие утверждения. Не использовал, не настраивал, но высказаться надо.
Airtrain
любитель "тихо сам с собой"? расскажи зачем соцсеточке в 2005м году транзакции? а так же Ceph, GlusterFS и остальные баззворды
khajiit
Для чего Ceph соцсеточке?
Это масштабируемое отказоустойчивое софтово-определяемое хоронилище, которой можно использовать для статики, например. А статики будет овердохренищща.
AcckiyGerman
Хоронилище! Хороните старую статику в /dev/null ибо фотки котиков и сисек каждый год одинаковые :) /сарказм
nochkin
Если одинаковые, то можно кешировать. А вот уже кеш надо хранить и быстро отдавать.
Airtrain
помнится file based storage ещё 10 лет назад считалось зашкваром, ещё когда глючный ceph в проде не использовали. но у хабра свой ритм жизни, ок, ок.... (не забудьте посрать в карму)
khajiit
То вам ceph — баззворд, то его противоположность — зашквар. Вы уж определитесь ))
rkfddf
Это зарплаты в Америке или где либо на загнивающем. Там реально джунам столько платят. Даже первая работа в нормальной фирме будет оплачиватся прилично больше.
Pas
Есть такое выражение — "голь на выдумки хитра". Как раз обмазывание всего и вся кубами, цефами, особенно хитрыми CI/CD и так далее делает даже минипроекты местами излишне сложными в эксплуатации. Что, к слову, выгодно облачным вендорам.
Как раз вымирает скилл как из говна и палок слепить относительный web хай лоад, не жрущий денег. За много денег это и каждый дурак сможет, а вот когда денег не так, чтобы много, тут уж и возникают вопросики. И да, всякие стэкируемые коммутаторы не были особой необходимостью для web-проектов, это больше прерогатива кровавого энтерпрайза (хотя нынче уже сложно найти нормальный управляемый свитч без поддержки стека).
M_AJ
Честно говоря, не представляю, как сделать нормальный high availability за мало денег. Добиться высокой доступности можно только путем резервирования всех критических компонентов системы, если не будет резерва, то с ненулевой вероятностью однажды возникнет ситуация, как у RUVDS, когда волей случая прилетело в ту самую единственную критическую точку. А резервирование всегда стоит денег.
Я кстати ничего не писал в своем сообщении про Кубер, а то что описал считаю минимальным действительно рабочим комплектом для HA-системы с более-менее сложным приложением, использующим что-то помимо единственной БД с репликой. Если знаете как сделать проще, то с удовольствием почитаю.
BugM
Несколько А записей + nginx на входе * 2 датацентра + сколько надо аппликейшен серверов * 2 датацентра + 2-3 (зависит от) реплики вашей любимой sql бд тоже в паре-тройке датацентров.
Минимальный отказоустойчивый хайлоад готов.
Всякие кубернетисы в нем просто не нужны. Это излишнее усложнение.
M_AJ
Так я в своём сообщении и не писал про Кубернетис.
Посыл статьи то был в том, что стоит только освоить Линукс и вы будете экономить большие деньги, самостоятельно хостя все на свете, а потом вообще все свели к выбору дистрибутива.
Ну да, если арендовать сервера в датацентрах, или поставить их там, то часть того о чем я написал (например подключение нескольких линий связи, настройка коммутаторов, роутеров, кластер виртулизации) уже будет сделано другими людьми.
Что касается нескольких А-записей то это работает не очень надежно, в чем я убедился на практике. На одной из работ было так и сделано — две серверных в разных городах с идентичными сервисами и две А-записи. Проблемы вызывают провайдерские DNS, и DNS дешевых роутеров, которые порой категорически отказываются возвращать несколько А-записей.
BugM
Сервера конечно арендуем. Aws не надо, но и полный треш не надо.
С одной стороны это решение на минималках. Оно не идеальное.
С другой а чего бы ему ломаться? Nginx ломаться не склонен. Перед опасными действиями, какое-нибудь большое обновление сервера или nginx, вырубаем его из днс и катим спокойно. Остаётся только сценарий сломавшегося сервера или всего датацентра. Риск для высокодоступного сервиса на минималках выглядит приемлемым. Чтобы его исключить надо уже довольно сложные и дорогие штуки делать. L2 балансировки там всякие.
schamberg97
@Pasи не говорит, что не нужно делать HA. Речь шла о том, что не надо перегружать архитектуру ненужными компонентами, для которых потом и прийдётся думать о резервировании.
M_AJ
А мой коммент о том, что если вы решили экономить и хостить прямо всё сами, полностью на своей инфраструктуре, то вам не хватит одного только Линукса и всего нескольких месяцев на обучение, тогда как посыл статьи – потрать на Линукс несколько месяцев, и сэкономь десятки тысяч долларов, даже при домашнем использовании. И это не метафора, прямо так и написано, даже цифры есть, $50-75к
askharitonov
Ну от операционной системы тоже многое зависит. Есть давние истории, как люди даже забывали, где у них находится сервер, при том, что годами с ним работали. Впервые прочитал такую историю про случайно замурованный компьютер с FreeBSD, потом и сам с таким столкнулся: рассказали, что первый сервер, который я настраивал (на RedHat 7.3) чуть не забыли при переезде, потому что его поставили в отдельном помещении, заставили коробками, и забыли про него :-) Обнаружили потому что не поленились пересчитать компьютеры в локальной сети и сравнить с тем, что реально присутствовало. Ну так вот, ни разу не слышал такую историю про Windows, ну и тем более тогда. Windows XP (система того времени, ну пусть и не для серверов) без установленных обновлений вообще жила в Интернете минуты (межсетевой экран предусмотрен не был).
uuger
У одного из моих клиентов, провинциального музея, был сервер на NT, на котором крутилось вообще всё, от файлопомойки до веб и прокси с почтой. И он продолжал жить на столь же древнем железе годы спустя после выхода последнего сервис-пака. В режиме 24х7х365
daggert
У нас в научном учреждении есть сервер на 2000 с почтой, древней как сами понимаете что, которая работает в аптайме в пару тысяч дней. Там конечно нагрузки так себе, человек 500 всего, но таки пашет, и даже с древним айдые винчестером. И торчит в мир (:
miarh
У меня таких 4. Ибо там софт, который больше нигде не работает. Сколько там аптайм - хз. В мир не торчат и когда туда заходил админ... ну не вспомнить :)
yoz
Не так давно для замены оперативки выключал сервер с 2012r2 с аптаймом 2000+ дней. Вполне обычная система винда для сервера. Единственное что я бы не стал винду высовывать наружу в интернет, т.к. сильно более дырявая штука. Но в интранете вполне ничем не хуже.
Ign0r
Лет 20 с лишним тому назад писали про замурованный сервер в университете Северной Каролины, который 4 года не могли найти.Так он под Novell крутился. Думаю что случай был не единичный...
vorphalack
я сам году в 10 примерно такой сервер оставил на ставшей бывшей работе, мы и сами раз в полгода не с первого раза вспоминали, где он там.
фряха + read-only rootfs на флешке, засунутая в внутристенный шкаф. там по-моему единственная шевелещаяся деталь была кулер бп
degtiv
на моём первом проекте на ms windows server 2000 аптайм составил несколько лет. На нём крутился локальный сервер местной конторы (почта, внутренний портал) с посещаемостью в несколько сотен человек ежедневно, плюс файлопомойка на несколько сотен гигов. Переезд на юникс был очень болезненным как для юзверей, так и для сисадминов
sena
Ну, если социалочка ляжет на часик раз в год, никто не умрёт. А вот неправильно выбранный дистрибутив может обойтись значительно дороже...
mc2
Если вы не знаете как его готовить, то без разницы какой дистрибутив выбрать.
«В критической ситуации ты не поднимешься до уровня своих ожиданий, а упадешь до уровня своей подготовки».
ZillahGiovanni
Попробуйте поднять "кластер" на Arch Linux и поподдерживайте это хотя бы с годик.
Выбор дистрибутива важен, т.к. это основа инфраструктуры.
khajiit
Если к инфраструктурным тестам добавить [ALA/ARM](https://wiki.archlinux.org/title/Arch_Linux_Archive] — никаких проблем.
Вот если в лоб решать — да, может стать больно.
Pas
На самом деле, столкнулся с тем, что современные популярные кластерные решения в большинстве своём вообще очень плохо переживают on-line обновление версии, так что хоть Убунта, хоть RHEL, хоть Arch, поднял, настроил и потом лучше особо не трогать, не обновляя ни сам кластер, ни базовую ОС, на которой всё это крутится. Зачастую, какой-либо существенный апгрейд превращается в сборку нового кластера и последующую миграцию данных. Так что если арч не обновлять и не поломается внезапно ничего ))
ZillahGiovanni
Какая связь между OS и кластеризованным сервисом?
Проблема арча еще в том, что на него и поставить ничего нельзя через некоторое время без приседаний.