в смысле вы хотите, чтобы для вас разработали социальную сеть - а за это вы человека наймете на работу? После того, как сеть будет разработана?
в крации как-то так
Charlie
Александр
вообще-то спрашивает он не об этом :)
Спрашивают о том, как понять, дошло ли у них до девопса и как определить эти рамки или я не так понял что-то?
Иван
CMMI видели? вот об этом.
Magistr
Когда процессы позволят вам делать 10 релизов в день, тогда можно считать у вас есть девопс культура
Александр
Иван
понятно, что все эти модели оценки больше маркетинговый продукт и мало отношения имеют к реальной жизни, а тем более к майндстоемким темам как Agile и DevOps. мне интересно лишь есть модели асессмента или нет.
Logan
Спрашивают о том, как понять, дошло ли у них до девопса и как определить эти рамки или я не так понял что-то?
ну в общем-то да. И это вопрос не про сам девопс, а о том, как измерять. Тут у нас девопс, не девопс или девопса на полстакана
Logan
Когда процессы позволят вам делать 10 релизов в день, тогда можно считать у вас есть девопс культура
плохое определение, опасное. И вы сами это понимаете
Magistr
плохое определение, опасное. И вы сами это понимаете
Да понятно что подразумеваеться под капотом еще и большой айсберг того что должно быть сделано чтобы правильно достичь результата
Иван
да, мы делаем десятки релизов в день... но это НЕ ТЕ релизы )
Logan
Да понятно что подразумеваеться под капотом еще и большой айсберг того что должно быть сделано чтобы правильно достичь результата
иииии теперь нам надо придумать метрики! А вот тут попа
Magistr
да, мы делаем десятки релизов в день... но это НЕ ТЕ релизы )
а какие это релизы ? не в прод ?
Logan
или сервисы. А хочется всю инфраструктуру
Magistr
иииии теперь нам надо придумать метрики! А вот тут попа
Ну можно начинать плясать от бизнес задач, нафига вообще девопс бизнесу.
Иван
в прод... просто объем действий и их характер по каждому релизу не может нам пока еще сказать, что хотя бы CD это
Magistr
в прод... просто объем действий и их характер по каждому релизу не может нам пока еще сказать, что хотя бы CD это
А вот деплой по 1й кнопке тоже хорошая задача
Logan
Ну можно начинать плясать от бизнес задач, нафига вообще девопс бизнесу.
нет. Вопрос был - как измерить абстрактную степень девопснутости в бизнесе. Да-нет-50%. И для этого нужна метрика
Иван
скорее не да/нет/50% а "базис-норма-продвинутый-ваще космос"
Magistr
чеклист сделать ? )
Иван
типа того, только очень сложный чек-лист. и прежде чем его делать, хотелось понять может уже есть модели. в этом мой вопрос и был. похоже, что их нет.
Alexander
нужно посчитать степень девопснутости админов? это чтобы диагноз им поставить? 😊
Magistr
All components are deployed and configured in "one click"
Log rotation is enabled for most critical components
Startup scripts are exist for all supported software components. Any service is started after system reboot.
It's possible to roll changes back after regular release
Logs should be collected in storage with ability to find required log records
Usage of the system resources must be collected in central storage as well as some general metrics for used stack of techologies
Backups for application data must be performed on a regular basis
Initiation of new servers automatically (including autoscaling) must be provided
Magistr
у нас вот такой чеклист есть
Magistr
за каждым пунктом еще стоит дока с тем а как правильно это делать у нас какой набор технологий и соглашений с другими отделами
Иван
нужно посчитать степень девопснутости админов? это чтобы диагноз им поставить? 😊
да не админов, а организации целиком: люди, процессы, технологии, культура, итд итп
Alexander
вообще, идея плясать от бизнес-задач мне нравится
Alexander
может быть, вам и не нужно всё это и будут лишь лишние затраты на ненужные вещи
Alexander
например, мне не нужны релизы 1 раз в день и чаще, 1 раз в 2 недели - норм
Alexander
а значит, можно не внедрять какие-то вещи для поддержки этого процесса
Александр
а значит, можно не внедрять какие-то вещи для поддержки этого процесса
Сегодня не нужно, завтра нужно. :-\
Alexander
так вот когда будет нужно - тогда и внедрять
Aleksandr
devops assessment нагугливает достаточно разных (неунифицированых) способов оценки, онлайн-тесты и т.д.
Magistr
All components are deployed and configured in "one click"
например подразумевает единое версионирование кода в репозитариях + 1 раз собираем артефакт и деплоим на кучу окружений, единообразные скрипты деплоя, и вот в таком духе
Александр
так вот когда будет нужно - тогда и внедрять
Ну вообще, вы об этом должны думать заранее или хотя бы прогнозировать, что вам может понадобиться выкатывать обновы 1 раз в 3 часа
Maxim
Alexander
к примеру, есть проект с 1 программистом, который кроме него никто не делает, проект нужно релизить примерно 1 раз в 2 недели (все правки туда могут подождать), если так - то никакая CI вообще не нужна, все тесты этот программист может просто запустить на своём компе с том же контейнере... единственное требование к нему - коммитить и пушить в удалённый репозиторий каждый день если были правки, если у компании все такие проекты - им и CI не нужна, если каждый локально пилит свой проект (модуль) на удалёнке и просто пушит в репозиторий...
Alexander
и в данной ситуации просто нет смысла заставлять эту компанию внедрять CI
Alexander
кроме того, есть различные системы общения для команды, например, слэк или хипчат.. но если там в команде 1 человек - опять же, эти системы не нужны
Rinat
да но это упрощает переход проекта от одного программера к другому, так как кнопку нажать в jenkins проще, + ключа деплоя в женкинсе
Rinat
или документацию писать надо
Alexander
тут может получиться так, что затраты на поддержку системы будут больше, чем польза (выраженная в денежном виде) от этой системы
Magistr
А еще есть хорошее добавление это infastructure as code
Rinat
ну это можно почти обо всем гооврить)), бекапы тогда тоже затратны
Rinat
их же нужно делать ) + их надо хранить
Rinat
+ проверять
Alexander
бэкапы затраты, да, если вам дешевле с 0 восстановить данные, чем поддерживать бэкапы - не делайте бэкапы
Alexander
я не все вещи храню
Alexander
например, те же сертификаты Let's Encrypt
Alexander
потеряются - фиг с ними, новые сгенерирую
Alexander
или логи
Pavel
кстати, логи важны бывают
Pavel
ближайшее 10 дней))
Alexander
ну да, просто переводим всё в деньги и считаем прибыль и риски от тех или иных решений
Alexander
делаем как выгоднее
Александр
ну да, просто переводим всё в деньги и считаем прибыль и риски от тех или иных решений
Кто будет их считать? Т.е. не так, кто их должен считать?
Alexander
тот, кто принимает решения и несёт ответственность за них
Александр
Странная логика, обычно этому человеку нужно что б в инфру вкладывали больше денег, ибо они уходят туда как в пропасть
Alexander
но вы же понимаете, что у каких-нибудь топ-менеджеров просто нет ни времени, ни компетенций, чтобы решить, нужно ли бэкапить вот такие-то логи или нет
Alexander
эти решения делегируют девопсам
Александр
Я понимаю это - но эти "топ-менеджеры" - это должны "понять и простить "(с)😆
Logan
ну да, просто переводим всё в деньги и считаем прибыль и риски от тех или иных решений
золотые слова. Почему-то 90% специалистов вообще не хотят это понять
Александр
золотые слова. Почему-то 90% специалистов вообще не хотят это понять
А формула есть? А то у меня с абстрактным мышлением не оч.
Alexander
Я понимаю это - но эти "топ-менеджеры" - это должны "понять и простить "(с)😆
я вижу это так [могу ошибаться, впрочем]:
- если девопс и менеджер - наёмные люди, они в первую очередь думают о себе и могут неэффективно расходовать средства, перестраховываясь (можно потратить несколько млн рублей на какую-нибудь СХД, чтобы бэкапить туда вообще всё, плюс от этого - риски сведены к минимуму, если что-то сломается - владелец бизнеса / вышестоящий менеджер не разозлится и не уволит меня), даже если это просто какой-то мелкий проект, у которого и прибыли нормальной нет, для них важнее их собственная репутация в глазах вышестоящих структур, чем что-то там ещё
- если девопс и менеджер - собственники (например, это 3 стартапера делают проект), они платят из кармана свои деньги, а не расходуют чужие, они не будут вот просто так всё бездумно бэкапить , им важна реальная эффективность вложений средств, они не боятся, что кто-то их уволит, для них эффективность расходования денег гораздо важнее [плюс у них может быть инвестор, который за всем следит и тут страх перед инвестором, а не перед потерями в случае поломки]
вот мне всегда ближе второй подход (потому что обычно я на всё трачу свои деньги [или те, которые могли бы стать моими, если бы я их не истратил], а не чьи-то там)
Alexander
так что совет - не надо просто так что-то внедрять, потому что так модно (DevOps / Agile / ITIL ), а считайте
Denis 災 nobody
А потом один решил что логи не нужны, второй не знал, авария, логов нет. Разосрались, распались на 2 компании. Поэтому лучше, когда кто-то формально самый главный
Alexander
в команде из 3 человек обычно есть просто закрытый чатик, где все трое решают вместе все вопросы
Александр
в команде из 3 человек обычно есть просто закрытый чатик, где все трое решают вместе все вопросы
Не обязательно, что кто-то решил, может быть был пьян и сломал логи или ещё какая ошибка была и все логи пропали, а бэкапов нет, ещё и база упала, потеряны транзакции и т.д., излишнее резервирование тоже плохо, но по сути, оно в такой ситуации может помочь.
Александр
Но вы же приняли решение, не бэкапить эту сферу, а сделать упор на производительность или ещё какую-то неведомую хрень.
Александр
Просто пример.
Alexander
когда принимается решение о логах - это всё должно учитываться, то есть во сколько обойдётся потеря логов, как часто такая потеря будет возникать, во сколько обойдётся внедрение системы логов (кап затраты), во сколько обойдётся поддержка (операционные затраты)
Александр
Alexander
я бюрократ)))
Александр
Не знаю даже, плохо это или хорошо. 😊
Alexander
ну можно просто в чатике минут 30 пофлудить/пообсуждать про бэкапы, какая вероятность , что метеорит в датацентр или кто-то большой попой сядет на сервер и проломит и насколько все остальные будут огорчены)) пока команда маленькая - там всё делается сообща, разделения труда почти нет, конечное решение за тем, кто больше других в этом разбирается, но участвуют обычно все