Уже даже BizDevSecOps получается, если всё сложить. Что дальше?
FinOps тут еще в соседней статье недавно придумали, правда в виде должности, а не концепции.
У меня rss-ленты интересующих меня источников собираются в Feedly, ленту которого я просматриваю раза три-четерыре в сутки. При этом самые интересные новости и полезные статьи я открываю и читаю сразу, то что звучит интересно но нет времени смотреть сейчас — помечается для раздела Read It Later. Read It Later я открываю тогда, когда в ленте Feedly всё просмотрено. И по той же схеме — то что заинтересовало прямо сейчас — читаются сразу и убирается, то что по-моему мнению может быть полезно, или может заинтересовать позже, но на что времени нет — сохраняю в Pocket с добавлением тегов. И потом когда понял что пора посмотреть материалы на определенную тему — захожу в Pocket в определенный тег, и просматриваю накопленные материалы.
Вот бы еще у него была новая полная документация, вместо тикетов джиры и гугл групс. Каждое действие в сторону от hello world пайплайна — и вот ты уже роешь гугл, стековерфлоу, джиру, сорцы плагинов в поисках того, что должно было быть написано в его документации. А учитывая что там весь функционал на плагинах…
Вобщем мне GitLab CI уже только поэтому гораздо больше нравится.
Когда писать нечего, но что-то в блог выложить нужно. Полностью согласен с zirexx.
Упомянули полтора инструмента, да еще каша какая-то. Вместо либо комплексного сравнения большинства инструментов (да и то уже было не раз), либо глубокого анализа и личного опыта эксплуатации по одному из них (лучший вариант).
Безусловно вы правы. Просто говорю о том чтобы не воспринимали как серебряную пулю. Тем более глядя на скорости создания резервной копии можно автоматически подумать что и достать ее можно будет также быстро. А потом оказывается что нет.
А тот же restic сам ценю и широко применяю.
Минус подобных решений — низкая скорость восстановления данных из бекапа. Говорю на примере restic, но подозреваю что у других тоже. Доставать данные из снапшота достаточно долго, монтировать снапшот в фс — еще дольше. Так что низкий MTTR — мимо.
Будет очень полезно в моем случае, когда рабочий комп и все инструменты на linux, а домашняя система — windows. И когда нужно поработать из дома — это сплошные пляски с бубнами, в попытках заставить виндовый vscode дружить с гитом, ансиблом и терраформом из wsl. И расширения неработающие не добавляют удобства. А вот так как описано в статье — будет очень неплохо.
Мой отзыв про содержание оригинальной статьи, к вашим примечаниями никаких претензий.
TOTP на смартфоне (естественно зашифрованном) и хранение резервных кодов в менеджере паролей — лучше чем смс.
SMS только в качестве кодов в дополнение к паролю — это еще нормально, но вот в качестве средства сброса пароля — ужас. В таких сервисах (как в пресловутой гугл почте) лучше номер телефона не давать вообще.
Соседство с историей про угон почты через клон симки (https://m.habr.com/ru/post/453286) делает эти советы похожими на издевательство. И ладно бы это был первый случай, но у угонов симок многолетняя история.
Привязывать второй фактор к настолько ненадежному каналу — дилетанство. Советовать такое — вредительство.
Точно, кажется уже любой гайд по докеру начинается с "докер — не ВМ", и всё равно такое мнение берется откуда-то.
Плюс вредные советы вроде открытия контейнеров в сеть хоста, вместо создания отдельных docker network — одной для связи между фронтом и беком, и одной между беком и бд. В docker-compose это две строчки.
Всего один абзац про новые уязвимости в процах Intel, а между тем это уже второй звоночек после уязвимостей Spectre.
Каждый год мы получали с выходом новых архитектур начиная с Sandy Bridge всего 5-10% прироста чистой производительности между поколениями, а теперь закрывая уязвимость прошлого года потеряли 30-40% производительности, и вот опять — отключаем HT, снова теряя столько же.
Шаг вперед и пять назад. Ощущение, что эволюция процессоров у Intel зашла куда-то не туда.
Спасибо за перевод, интересно.
И в очередной раз убеждаюсь в действенности старой шутки на новый лад: если у вас есть проблема и вы решаете ее с помощью кубернетис — теперь у вас две проблемы.
Понятно, что это цена за быстрое развертывание и низкий time-to-market, но сложность создаваемых для достижения этого систем и количество слоев абстракции — ужасно.
Начало статьи напомнило инструкцию по рисованию совы: 1. Рисуем два кружочка 2. Рисуем остальную сову.
А именно, в первом абзаце — определение BGP, и тут же вторым абзацем — уже команды ios, без пояснений.
Стоило бы тогда до ката написать, что статья требует знакомства с такими-то вещами, целевой уровень подготовки читателя.
Да, вот вроде и понятно примерно было о чем это, но после такой статьи — всё встало по полочкам окончательно. Теперь плюс одна метрика с осознанным смыслом.
Уже даже BizDevSecOps получается, если всё сложить. Что дальше?
FinOps тут еще в соседней статье недавно придумали, правда в виде должности, а не концепции.
Как раз в домашней системе i7-2600k + ddr3 16gb + sata ssd 256gb, win10. Задуматься о необходимости апгрейда повода нет до сих пор.
Вот бы еще у него была новая полная документация, вместо тикетов джиры и гугл групс. Каждое действие в сторону от hello world пайплайна — и вот ты уже роешь гугл, стековерфлоу, джиру, сорцы плагинов в поисках того, что должно было быть написано в его документации. А учитывая что там весь функционал на плагинах…
Вобщем мне GitLab CI уже только поэтому гораздо больше нравится.
Когда писать нечего, но что-то в блог выложить нужно. Полностью согласен с zirexx.
Упомянули полтора инструмента, да еще каша какая-то. Вместо либо комплексного сравнения большинства инструментов (да и то уже было не раз), либо глубокого анализа и личного опыта эксплуатации по одному из них (лучший вариант).
А тот же restic сам ценю и широко применяю.
Минус подобных решений — низкая скорость восстановления данных из бекапа. Говорю на примере restic, но подозреваю что у других тоже. Доставать данные из снапшота достаточно долго, монтировать снапшот в фс — еще дольше. Так что низкий MTTR — мимо.
TOTP на смартфоне (естественно зашифрованном) и хранение резервных кодов в менеджере паролей — лучше чем смс.
SMS только в качестве кодов в дополнение к паролю — это еще нормально, но вот в качестве средства сброса пароля — ужас. В таких сервисах (как в пресловутой гугл почте) лучше номер телефона не давать вообще.
Соседство с историей про угон почты через клон симки (https://m.habr.com/ru/post/453286) делает эти советы похожими на издевательство. И ладно бы это был первый случай, но у угонов симок многолетняя история.
Привязывать второй фактор к настолько ненадежному каналу — дилетанство. Советовать такое — вредительство.
Можно попросить статью в формате How-To с описанием процесса развертывания и настройки такого кластера?
Точно, кажется уже любой гайд по докеру начинается с "докер — не ВМ", и всё равно такое мнение берется откуда-то.
Плюс вредные советы вроде открытия контейнеров в сеть хоста, вместо создания отдельных docker network — одной для связи между фронтом и беком, и одной между беком и бд. В docker-compose это две строчки.
Каждый год мы получали с выходом новых архитектур начиная с Sandy Bridge всего 5-10% прироста чистой производительности между поколениями, а теперь закрывая уязвимость прошлого года потеряли 30-40% производительности, и вот опять — отключаем HT, снова теряя столько же.
Шаг вперед и пять назад. Ощущение, что эволюция процессоров у Intel зашла куда-то не туда.
Спасибо за перевод, интересно.
И в очередной раз убеждаюсь в действенности старой шутки на новый лад: если у вас есть проблема и вы решаете ее с помощью кубернетис — теперь у вас две проблемы.
Понятно, что это цена за быстрое развертывание и низкий time-to-market, но сложность создаваемых для достижения этого систем и количество слоев абстракции — ужасно.
А именно, в первом абзаце — определение BGP, и тут же вторым абзацем — уже команды ios, без пояснений.
Стоило бы тогда до ката написать, что статья требует знакомства с такими-то вещами, целевой уровень подготовки читателя.
Полезно. И про CASE подход к алертам узнал, и взгляд на собственные дашборды поменял, много вещей нужно улучшать.
Да, вот вроде и понятно примерно было о чем это, но после такой статьи — всё встало по полочкам окончательно. Теперь плюс одна метрика с осознанным смыслом.
Спасибо, интересно, добавило больше деталей к предыдущему рассказу про то, как готовили Clickhouse.