Здравствуйте, Sheridan, Вы писали:
S>Именно так. Твой софт слёг на проде. рукилицо.
Не прикидывайся идиотом настолько хорошо. Люди же верят...
Слёг мой софт по причине того, что его обрушил чужой софт, над которым у меня контроля нет.
S>А. Теперь понятно почему нет времени ни на что. Ты тестируешь всё со всем. Ясен хрен что не остаётся времени на свой софт.
Продолжай юродствовать, продолжай убеждать людей в том, что ты идиот. Ты достигаешь успеха.
S>Это должен делать заказчик. Сервера — его. Софт — он купил.
Поддержку он тоже купил.
S>Совместимость пусть проверяет сам. А потом вам в саппорт баги шлёт ежели что.
Ну, прислал он в саппорт запрос — "у нас тут кое-что упало и из-за этого ваш софт не работает, у нас есть договор на поддержку, помогите нам, пожалуйста". Легче стало?
S>Записывай, диктую; "Изучение проблемы выявило тот факт, что устаноленное рядом ПО в своём дистрибутиве имело устаревшую версию библиотеки Х, которую установило без соблюдения общепринятых правл в общесистемный каталог. Исправить проблему с нашим ПО можно, выполнив вот этот (ссылка) скрипт, который приведет наше ПО в рабочее состояние, но вероятно стороннее ПО перестанет работать. Возможные варианты решения проблемы: установить стороннее ПО на отдельный сервер, обратиться к поставщику сторонего ПО с просьбой актуализировать версию используемой библиотеки."
А как же "which allows the customer to save money by not allocating separate servers for our software"?
В трубу идет... Ну, никто не сомневался, собственно. Офигеть какая гибкость...
Впрочем, я тебе тоже напишу ответ клиента на это — "Изучение рынка выявило тот факт, что ваши конкуренты умеют изолировать свой софт, а вы нет. С учетом потерь от простоя, нам дешевле заплатить вам неустойку, разорвать контракт на поддержку и перейти к конкурентам".
S>Впрочем ты прав, для этого не надо плодить ни сервера, ни докеры. Можно вполне штатно такую проблему разрулить.
Ага, разведя ПО по разным серверам, как ты предложил выше...
S>Нет. У меня нет практики в английском. Перепиши по русски и поговорим.
Английский — основа для айтишника. Как ты работаешь, если ты понять простые тексты не можешь?
S>Может всётаки ты? Где тут противоречие?
Сильный ветер с куда большей вероятностью погубит твои морозоустойчивые огурцы, нежели те, что защищены теплицей.
Противоречие же в том, что ты сначала утверждал обратное.
Здравствуйте, Sheridan, Вы писали:
S>>>А ты ходить уже научился? C>>Да. А вы там ещё ползаете? S>У нас тут гравитация слабая, поэтому скорее летаем.
Это не гравитация слабая, это вы прямо в дерьме плаваете и дышите им.
C>>Хотфикс чего? JDK? Это занимает несколько дней для проведения полного цикла тестов. В таких случаях единственное решение — это откат до предыдущего состояния. А затем в спокойной обстановке уже разбираться со стратегией исправления ошибки. S>И в чём проблема? Откатили код обратно, сбросили изменения в отдельную ветку, собрали, задеплоили, тестируете. Багфикс пришёл — накатили фикс, накатили ветку. Тестируете.
Ну вот и как откатывать код? Обычные пакетные репозитории Линукса умеют только вперёд накатывать.
S>Но нет, надо обязательно делать прыжок обратно всем продом на всех клиентах, ага.
Именно. Такая возможность должна быть.
S>Просто перестань говорить. У тебя постоянно получается что всё критикал прилетает в заказчика. что сразу многое говорит о ваших производственных процессах.
Критические ошибки — они на то и критические, что появляются у заказчика. Всё что до заказчика не доходит — это всё не критическое по определению. Duh.
C>>У нас тестируется весь UI с помощью роботов, API с помощью интеграционных тестов, 85% кода сервисов покрыто unit-тестами. Вычислительные задачи валидируются на массиве тестовых данных и на задачах, которые запускались последние 2 недели. Помимо простого сравнения, используется AI для поиска аномалий (странное потребление памяти, увеличение времени работы и т.п.). S>Отлично. Почему тогда у вас так много инцидентов на проде заказчиков?
Потому, что реальность — она такая. В любой сложной системе будут непредвиденные взаимодействия и ошибки. Устранить это никак нельзя, но можно смягчить последствия.
C>>Каждые 6 месяцев мы отсылаем отчёты в правительство нескольких штатов для о результатах мониторинга реальных систем, построенных по нашим планам. Это нужно для поддержки сертифицированного статуса. S>Отлично. Почему тогда огромная проблема актуализировать используемые библиотеки?
Мы это делаем, обычно раз в несколько месяцев отдельным deploy'ем (за исключением дыр в безопасности). Как и в любой другой системе — гораздо проще менять только один параметр за раз, особенно если нет ограничений по времени.
S>>>Ну я так понимаю что ты хочешь спросить смогу ли я перехватить неперехватываемую ошибку, которая никогда категорически не перехватывается на тестах и обязательно рушит прод в ноль. C>>Именно так, да. Потому, что я так могу делать. S>Значит и я могу.
Вряд ли.
C>>Да-да, Докер позволяет успешно обрабатывать неожиданные ошибки. S>Приводящие к краху процесса? Системд тоже так умеет.
Systemd умеет многое из того, что делает Docker, так как они построены на тех же технологиях. Но он не умеет, например, бороться с переполнением диска и не умеет сам по себе запускать процессы в своих сетевых namespace'ах.
C>>Где мои $2000? Можно на PayPal: alex.besogonov@gmail.com S>Я не проиграл. Ты пропустил вспышку слева и пришёл мне доказывать что докер категорически нужен там где я изначально писал допустимость его использования.
Где бабки-то?
Здравствуйте, Sheridan, Вы писали:
C>>Именно между созданием и записью файла? S>А что изменится? Ну или будет скрипт который создаёт пустой файл и валится. Можно даже разбавить валидный церт мусором и не свалиться. Да что угодно.
Нет. Ты не понимаешь вообще что тебе говорят.
Для обнаружения этой ошибки нужно, чтобы тестовый протокол включал прерывание всех утилит в промежутке между каждым системным вызовом и проверки работоспособности системы после этого. Я знаю ровно один пакет, который тестируется таким образом (это sqlite).
C>>Тут есть целые дистрибутивы Линукса, которые только копированием работают... S>я в курсе что dd чудеса творит, да.
Я про https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/
C>>У Докера нет. Он хранит кэш слоёв (компонентов изображений), который автоматически чистится. S>Это и есть мусор.
Нет.
S>>>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд? C>>А такого не может быть (если на сервере не порылся админ Sheridan). S>Всмысле? Образ весит Х+1 мегабайт, очистилось Х мегабайт. Места нет.
Так не может быть, если только образ не больше всего диска. Иначе Docker просто удалит неиспользуемые слои, пока не наберётся достаточно места.
Здравствуйте, Sheridan, Вы писали:
S>>Не надо париться про то, какие там версии каких библиотек стоят и кто там с кем будет конфликтовать. S>Абсолютно верно, на стадии деплоя не надо. Надо на стадии разработки.
На стадии разработки подготовка софта к тому, чтобы он работал в достаточно любом окружении стоит очень больших денег.
Любой разработчик, кто распространял свой софт более чем одному клиенту об этом осведомлён.
Да, многие годы считалось, что "надо просто сильнее бить разработчиков". Потом была идея что "распространение софта — дело маинтейнеров дистрибутива", а разработчик должен выкласть только исходники.
Всё это в полночь оказалось тыквой — прекрасно работает только в воображении идеалистов.
На практике даже на уровне исходников сделать софт совместимым одновременно с тремя версиями LibSSL — уже тяжело. А маинтейнер дистрибутива выступает хреновым посредником между пользователем и разработчиком, особенно если это касается заказного софта.
Докер вовремя сообразил, что контейнеры, которые изначально позиционировались как легковесные VM, можно довести до логического завершения — "каждому приложению по машине".
S>Не надо, абсолютно верно. После поднятия хоста оно само поднимется.
Ну что за бред. Это даже не детский сад. А если хост вообще не поднимется? Хорошо, если на нём какой-то кратковременный сбой. А если там пожар в DC и вся стойка тово?
S>>Не надо париться с тем, позаботился ли разработчик о том, чтобы на одном хосте могли параллельно работать две версии рендерера, или как обычно "вместе могут работать 3 и 4, и 4 и 2, но не 3 и 2" S>Отучать разрабов от лени и учить читать ТЗ.
Шеридан, разработчиков в мире — миллионы. S>Ну и учиться ставить задачи конечно жэ.
Иди, пиши ТЗ постгресу, апачу, монгодб, и прочим. У тебя реально мышление технички — тебе все уже должны, а ты даже научиться пользоваться контейнерами в стиле "воткнул — заработало" не хочешь.
S>>Безо всех этих "да я щас там заднюю панель сниму, паяльничком чик-чик, и в понедельник уже заработает". S>Странное у тебя представление об ансибле, очень странное.
Ровно как ты рассказал. У тебя на каждый вопрос ответом идёт "да я там плейбук сделаю, если понадобится".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, XOOIOOX, Вы писали: XOO>Увлекательнейшее чтиво. "Спасение рядового Шеридана".
Не, просто, как известно, всякого человека в других бесят ровно те недостатки, которые есть у него самого.
Так что все эти споры — они не с Шериданом. Тут каждый воюет с внутренним шериданом, который есть у каждого
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Докер вовремя сообразил, что контейнеры, которые изначально позиционировались как легковесные VM, можно довести до логического завершения — "каждому приложению по машине".
Там ещё круче история была — Докер изначально был чисто внутренним инструментом, который выложили в OpenSource, в качестве рекламы компании. А он взял и выстрелил, так как решает практические задачи, которые случаются у всех.
S>Но нет, надо обязательно делать прыжок обратно всем продом на всех клиентах, ага.
Когда каждая минута простоя — это потеря денег, клиентов и репутации, то да, прыжок обратно всем продом на всех клиентах. Людям, которые никогда ни за что не были ответственны и ничего не знают за пределами тепличных условий это неизвестно, да. Людям, у которых мир ограничивается «обскриптуем со всех сторон» так же неизвестно, как можно откатить весь прод.
Здравствуйте, Sheridan, Вы писали:
S> AB>Несовместимость API, разное поведение в рамках одного API, (не)поддержка TLSv1.3, ряд CVE, шаманские танцы с отключением compression/SSLv3, история sha1/sha256, выход BoringSSL/LibreSSL, etc. S> Я слышу это только от вас. На практике никогда не встречался, хотя много где использовалосью
Ну... Печально, конечно, что это все прошло мимо человека, называющего себя системным администратором. Вдвойне печально, что в подтреде про безопасность ты категорически настаивал на безопасности личной домашней системы — дайджесты по базовые системным компонентам ты по долгу службы должен читать хотя бы по диагонали как брокер биржевую сводку.
S> S>> А берутся во внимание только трудозатраты программистов? Или всётаки вы командой работаете? S> AB>Берутся во внимание все затраты, риски и т.д. S> Ну тогда вы должны взять во внимание и трудозатраты девапса/админа на танцы вокруг окаменелостей.
Вне сомнения они так же учитываются. Что часто приводит к решению вида "Ничего не делаем, т.к. окаменелость не приносит столько пользы, сколько на ее обновление будет затрачено ресурсов — лучше займемся (все вместе) чем-то более продуктивным."
В сутках всего 24 часа. У админа есть семья, дети, ипотека, хобби и т.д. и т.п. Занимать его никому не нужной фигней совершенно непродуктивно с любой точки зрения.
S> AB>Из чего ты делаешь такой вывод?! Админу (нормальному) новые проблемы в проде совершенно не нужны, он не хочет просыпаться ночью 1-го января и чинить какой-нибудь внезапный пожар, он точно так же будет вовлечен в процесс принятия решения и рассматривать плюсы-минусы через призму своей области ответственности. S> И на этом этапе нормальный девапс/админ будет настаивать на переходе либ с окаменелостей на текущую версию.
Нормальный будет взвешивать плюсы и минусы подобного перехода с учетом мнения коллег. И если текущая ситуация стабильна, а профита от обновления нет, то и ну его нафиг это обновление ради обновления — работает, не трогай.
S> AB>Другие пути есть, но они на сегодняшний день являются слабо/неэффективными в промышленных масштабах. Ты можешь обрабатывать грядку мотыгой — никто слова не скажет, но в промышленных масштабах люди пользуются специализированной агротехникой и на предложение обработать поле мотыгой пытаются тебе объяснить, что ты неправ. S> Вот как раз ансибл это и есть комбайн, способный с нуля обрабатывать поля. А докер в этой аналогии — теплица, где каждый сам под себя грядки копает.
Ну если продолжать в этом же ключе, то пока ты ансиблом только начинаешь готовить поле, другие уже начинают растить урожай. Очевидно, что у них получится быстрее и с меньшими затратами. Паритет мотыга-комбайн не меняется.
S> S>> Я понимаю зачем докер. Я не понимаю почему только докер, исключительно докер, докер докер и кубернетес пророк его. S> AB>Ты не понимаешь зачем нужна изоляция и/или не принимаешь ее как технологию производства, а не зачем докер. S> Я не понимаю изоляцию ради изоляции.
Нет изоляции ради изоляции. Есть best practice, которые в большинстве случаев (почти всегда) экономят ресурсы на временном отрезке жизни продукта. При этом они сформулированы не просто в стиле "верь мне, я знаю", а под ними есть вполне рациональная база множество раз здесь описанная. Не пользоваться этим знанием — личный выбор. Отвергать его без настолько же рациональных контр-аргументов — невежество.
S> S>> Я понимаю почему версия библиотеки в проекте может отличаться от актуальной. Я не понимаю почему как только речь о актуализации заходит — начинается выдумывание 1000 и 1 способа почему это не нужно делать. S> AB>Потому что ты актуализацию делаешь самоцелью в то время как на практике эта операция относительно редкая (и обычно недешевая). S> Я не делаю её самоцелью. Это реакция на ваши утверждения что менять ничего не надо.
Не было подобных утверждений. Все утверждения были — не меняем без перевешивания плюсов над минусами vs твое меняем всегда.
Здравствуйте, Sinclair, Вы писали:
S>>Не надо, абсолютно верно. После поднятия хоста оно само поднимется. S>Ну что за бред. Это даже не детский сад. А если хост вообще не поднимется? Хорошо, если на нём какой-то кратковременный сбой. А если там пожар в DC и вся стойка тово?
это навело еще на аргумент — универсализация.
с докером плюс минус одинаково запускать что на своих серверах что в AWS что в Azure
S>Докер вовремя сообразил, что контейнеры, которые изначально позиционировались как легковесные VM, можно довести до логического завершения — "каждому приложению по машине".
Справедливости ради, в Microsoft после DLL hell тоже кое-что поняли, и, как бы это помягче, сделали свой вариант. Для .НЕТ.
Здравствуйте, Sheridan, Вы писали:
SD>>Бизнес — это про деньги, а не про ответственное отношение. S>Кек, у меня многие вопросы исчезли. Вот оно что оказывается. Тяп-ляп-лишь-бы-работало
Ты, как обычно, просто не понимаешь о чем речь. Когда у тебя в кластере, к примеру, 100К машин, обязательно что то будет постоянно отказывать, хоть порви свою задницу на британский флаг. И с этим надо уметь жить, а не надеятся что у тебя сбоев не будет потому что ты такой красивый.
Здравствуйте, Ночной Смотрящий, Вы писали:
SD>>>Бизнес — это про деньги, а не про ответственное отношение. S>>Кек, у меня многие вопросы исчезли. Вот оно что оказывается. Тяп-ляп-лишь-бы-работало
НС>Ты, как обычно, просто не понимаешь о чем речь. Когда у тебя в кластере, к примеру, 100К машин, обязательно что то будет постоянно отказывать, хоть порви свою задницу на британский флаг. И с этим надо уметь жить, а не надеятся что у тебя сбоев не будет потому что ты такой красивый.
Сбои будут, да. На такой куче машин я почти уверен что у тебя даже винты будут лететь со скоростью 1-3 в день. Я в курсе.
Но тут не про это. Тут про то что бабло важнее ответственного отношения. Почитай то что я процитировал.
Здравствуйте, Sheridan, Вы писали:
S>Но тут не про это.
Тут именно про это.
S> Тут про то что бабло важнее ответственного отношения.
Что за неведомый зверь — "ответственное отношение" и как его измерить?
Есть вполне конкретная штука — SLA. Каждая чиселка в ней — вполне конкретные и ощутимые бабки. И бизнес выбирает ровно тот уровень, за который он готов платить. И если ты ему предложишь уровень, за который он не хочет платить — ты пойдешь в лес. Никакого "ответственного отношения" же в этом уравнении нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Тут про то что бабло важнее ответственного отношения.
НС>Что за неведомый зверь — "ответственное отношение" и как его измерить? НС>Есть вполне конкретная штука — SLA. Каждая чиселка в ней — вполне конкретные и ощутимые бабки. И бизнес выбирает ровно тот уровень, за который он готов платить. И если ты ему предложишь уровень, за который он не хочет платить — ты пойдешь в лес. Никакого "ответственного отношения" же в этом уравнении нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А никто и не агитирует за фанатизм. НС>Это вот твое "ответственное отношение" вопреки потребностям бизнеса — самый настоящий фанатизм и есть.
Вопреки??? С какого это лешего — вопреки? Я вам тут талдоню что помимо программеров в команду нужны админы, чтобы разгрузить программеров от не-их работы (чтобы они больше фич релизили), чтобы помогать программерам деплоить/пакетировать их продукт. В команду, комораде. Не руководителем, не коммандиром, не рабом. В команду, что значит сообща работать.
И ВНЕЗАПНО я чтототам против бизнеса.
Здравствуйте, Sheridan, Вы писали:
S>>>А никто и не агитирует за фанатизм. НС>>Это вот твое "ответственное отношение" вопреки потребностям бизнеса — самый настоящий фанатизм и есть. S>Вопреки???
Вопреки.
S>С какого это лешего — вопреки?
С того что ты ополчился против того чтобы следовать требованиям бизнеса и в альтернативу им вытавляешь непонятное "ответственное отношение".
S> Я вам тут талдоню что помимо программеров в команду нужны админы, чтобы разгрузить программеров от не-их работы (чтобы они больше фич релизили)
Нет, ты тут рассказывал про ответственное отношение, а не про админов. Завилял, да еще и на редкость топорно.
S>И ВНЕЗАПНО я чтототам против бизнеса.
А это что, по твоему?
Но тут не про это. Тут про то что бабло важнее ответственного отношения.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>>А никто и не агитирует за фанатизм. НС>>>Это вот твое "ответственное отношение" вопреки потребностям бизнеса — самый настоящий фанатизм и есть. S>>Вопреки??? НС>Вопреки.
S>>С какого это лешего — вопреки? НС>С того что ты ополчился против того чтобы следовать требованиям бизнеса и в альтернативу им вытавляешь непонятное "ответственное отношение".
Требования бизнеса — "пишите хрень, лишь бы абы как работало и нам срать сколько боли будет у юзера при установке наших поделий"?
Хреновый бизнес. Никуда не годный. Позволит сорвать куш на быстром старте такой подход, но постоянно его использовать — глупо.
S>> Я вам тут талдоню что помимо программеров в команду нужны админы, чтобы разгрузить программеров от не-их работы (чтобы они больше фич релизили) НС>Нет, ты тут рассказывал про ответственное отношение, а не про админов. Завилял, да еще и на редкость топорно.
А это и есть про ответственное отношение. Каждый специалист занимается своим делом, а не "а, васян линупс настроит, он его два года назад с лайвсиди смотрел".
S>>И ВНЕЗАПНО я чтототам против бизнеса. НС>А это что, по твоему? НС>
НС>Но тут не про это. Тут про то что бабло важнее ответственного отношения.
Здравствуйте, Sheridan, Вы писали:
НС>>С того что ты ополчился против того чтобы следовать требованиям бизнеса и в альтернативу им вытавляешь непонятное "ответственное отношение". S>Требования бизнеса — "пишите хрень, лишь бы абы как работало и нам срать сколько боли будет у юзера при установке наших поделий"?
Может быть и такое.
S>Хреновый бизнес. Никуда не годный.
Хреновый бизнес это называть бизнес заказчиков хреновым. Смысл коммерческой разработки в удовлетворении требований заказчика, а не в почесывании своих мудей.
НС>>А это что, по твоему? НС>>
НС>>Но тут не про это. Тут про то что бабло важнее ответственного отношения.
