BeerPanda. Органично недоразвитый DevOps

Когда слышал про NUMA, но не понял как все это работает.

Встретил вот такую интересную статью, в которой предлагают бороться с NUMA через CPU Affinity

Краткий комментарий от меня:

1. Задача поддерживать NUMA locality - задача гипервизора
2. Чем больше инфраструктура - тем меньше в нее надо лезть руками
3. При задании CPU affinity слетает миграция и балансировка
4. CPU affinity не имеет смысла, если гипервизор память выделил НЕ на на том же узле

Ну и отдельные перлышки.

В рабочих окружениях мы обычно имеем дело с серверами на 32 и больше ядер.

NUMA массово в x86 появилась во времена Xeon 55xx Nehalem, 2008 год. От 2 до 8 ядер на процессор.

А для работы с большими объёмами оперативки - Non-Uniform Memory Access (NUMA).

Для сокращения пути ядро<->память, а не для большого объема. Объем-то как раз не проблема нарастить, только все упрется в пропускную способность и задержки.

Но виртуальные машины не имеют информации о том, как устроены NUMA-узлы и ядра на хосте

Поэтому размещением машин и локальностью NUMA занимается гипервизор. В этом весь смысл виртуализации.

Но в реальном продакшене

В реальном продакшене количество узлов в кластере может составлять десятки хостов. ВМ постоянно создаются, включаются, выключаются, перемещаются (живая миграции). Как результат идет фрагментация памяти. А управлять процессор должен планировщик процессора и менеджер памяти гипервизора.
Использования CPU affinity для борьбы с NUMA - уровень "чтобы быстрее ползать надо отрубить ноги".

Из древности ИТ в наши дни. 3

Терминальные серверы

Повсеместное распространение все более и более мощных персоналок на периферии значительно опережало развитие сетей общего доступа. Классические для 90-начала 00 клиент-серверные приложения не очень хорошо работали по тонкому каналу, если обмен данными составлял сколько нибудь значимые значения. Особенно это было тяжело для удаленных офисов, подключавшихся по модему и телефонной линии, которая к тому же периодически подвисала или обрывалась. И…

Спираль сделала виток и оказалась снова в терминальном режиме с концепцией терминальных серверов.

Фактически мы вернулись к 70м с их нулевыми клиентами и централизацией вычислительной мощности. Очень быстро стало очевидно, что помимо чисто экономической подоплеки с каналами терминальный доступ дает огромные возможности по организации безопасного доступа снаружи, в том числе работы из дома для сотрудников, или крайне ограниченного и подконтрольного доступа контракторам из недоверенных сетей и недоверенных/неконтролируемых устройств.

Однако терминальные серверы при всех их плюсах и прогрессивности, обладали также и рядом минусов — низкая гибкость, проблема шумного соседа, строго серверная Windows и тд.

Рождение прото VDI

Правда в начале-середине 00х уже вовсю выходила на сцену промышленная виртуализация x86 платформы. И кто-то озвучил попросту витавшую в воздухе идею: а давайте вместо централизации всех клиентов на серверных терминальных фермах дадим каждому его персональную ВМ с клиентской Windows и даже администраторским доступом?

Отказ от толстых клиентов

Параллельно с виртуализацией сессий и ОС развивался подход, связанный с облегчением функции клиента на уровне приложения.

Логика за этим была довольно простая, ведь персональные ноутбуки были все еще далеко не у всех, интернет точно так же был не у всех, и многие могли подключиться только из интернет кафе с очень ограниченными, мягко говоря, правами. Фактически, все что можно было запустить — это браузер. Браузер стал непременным атрибутом ОС, интернет прочно заходил в нашу жизнь.

Иными словами, параллельно шел тренд на перенос логики с клиента в центр в виде веб-приложений, для доступа к которым нужен только самый простой клиент, интернет и браузер.
И мы оказались не просто там же, с чего начинали — с нулевых клиентов и центральных серверов. Мы пришли туда несколькими независимыми путями.

Из древности ИТ в наши дни. 2

“Наши дни” я бы стал отсчитывать с начала 80-х, с момента появления первых доступных широкому кругу процессоров со сколько нибудь значимой вычислительной мощью. Традиционно считается, что главным процессором эпохи стал Intel 8088 (семейство x86) как родоначальник победившей архитектуры. В чем же принципиальная разница с концепцией 70х?

Появляется тенденция переноса обработки информации из центра на периферию. Далеко не все задачи требуют безумных мощностей мейнфрейма или даже мини-компьютера. Intel не стоит на месте, в 90х выпускает семейство Pentium. Эти процессоры уже способны на многое, не только написать письмо — но и мультимедиа, и работать с небольшими базами данных. Фактически для малого бизнеса полностью отпадает необходимость в серверах — все можно выполнять на периферии, на клиентских машинах. С каждым годом процессоры все мощнее, а разница между серверами и персоналками все меньше и меньше.

Если сравнивать современные клиентские процессоры “смешной” для администраторов тяжелых серверов в 90е компании Intel с суперкомпьютерами прошлого, то и вовсе становится слегка не по себе.

Давайте взглянем на старичка, всего-то практически моего ровесника. Cray X-MP/24 1984 года.

Эта машина входила в топ суперкомпьютеров 1984, имея 2 процессора по 105 MHz с пиковой вычислительной мощностью 400 MFlops (миллионов операций с плавающей точкой). Конкретно та машина, что изображена на фото, стояла в лаборатории криптографии АНБ США, и занималась взломом шифров. Если перевести 15 млн долларов 1984 года в доллары 2020, то стоимость составит 37,4 млн, или 93 500 долларов / MFlops.


В той машине, на которой я пишу эти строки (текст 2020 года), стоит процессор Core i5-7400 2017 года, не новый, и даже в год своего выхода самый младший 4-ядерным из всех десктопных процессоров среднего уровня. От 19 до 47 GFlops по разным тестам при цене 16 тыс руб за процессор. Если собрать машинку целиком, то можно принять ее стоимость за 750 долларов (по ценам и курсу на 1 марта 2020).

В конечном итоге получаем превосходство вполне среднего десктопного процессора наших дней в 50-120 раз над суперкомпьютером из топ10 вполне обозримого прошлого, а падение удельной стоимости MFlops становится совсем чудовищными 93500 / 25 = 3700 раз.

Зачем нам все еще нужны серверы и централизация вычислений при подобных мощностях на периферии — решительно непонятно!

Бездисковые станции

Первым сигналом, что вынос вычислений на периферию не будет окончательным, стало появление технологии бездисковых рабочих станций. При значительном распределении рабочих станций по территории предприятия, и в особенности в загрязненных помещениях, очень жестко встает вопрос управления и поддержки этих станций.

Появляется понятие “корридорное время” — те процент времени, что сотрудник техподдержки находится в коридоре, по дороге к сотруднику с проблемой. Это время оплачиваемое, но совершенно непродуктивное. Далеко не последнюю роль, и в особенности в загрязненных помещениях, составляли выходы из строя жестких дисков. Давайте уберем из рабочей станции диск, а все остальное сделаем по сети, в том числе загрузку. Сетевой адаптер получает помимо адреса от DHCP сервера так же дополнительную информацию — адрес сервера TFTP (упрощенный файловый сервис) и имя загрузочного образа, загружает его в оперативную память и стартует машину.

Помимо меньшего количество поломок и снижения коридорного времени, машину теперь можно не отлаживать на месте, а просто принести новую, и забрать старую на диагностику на оборудованное рабочее место. Но и это еще не все!

Бездисковая станция становится значительно безопаснее — если вдруг кто-то вломится в помещение и вынесет все компьютеры, это лишь потери оборудования. Никаких данных не хранится на бездисковых станциях.

Запомним этот момент, ИБ начинает играть все большую роль после “беспечного детства” информационных технологий. А в ИТ все сильнее вторгаются страшные и важные 3 буквы — GRC (Governance, Risk, Compliance), или по-русски «Управляемость, Риск, Соответствие».

Из древности ИТ в наши дни. 1

Я расскажу вам сегодня краткую историю. Историю эволюции вычислительной техники и появления удаленных рабочих мест с древнейших времен и до наших дней.

Главное, что можно вынести из истории ИТ — это…

Разумеется то, что ИТ развивается по спирали. Одни и те же решения и концепции, которые были отброшены десятки лет назад, обретают новый смысл и успешно начинают работать в новых условиях, при новых задачах и новых мощностях. В этом ИТ ничем не отличается от любой другой области человеческого знания и истории Земли в целом.

“Я думаю, в мире есть рынок примерно для пяти компьютеров”, глава IBM Томас Уотсон в 1943.

Ранняя компьютерная техника была большой. Нет, неправильно, ранняя техника была чудовищной, циклопической. Полностью вычислительная машина занимала площадь, сравнимую со спортивным залом, а стоила совершенно нереальных денег. В качестве примера комплектующих можно привести модуль оперативной памяти на ферритовых кольцах (1964).

Этот модуль имеет размер 11 см * 11 см, и емкость в 512 байт (4096 бит). Шкаф, полностью набитый этими модулями, едва ли имел емкость древней уже на сегодня дискеты 3,5” (1.44 МБ = 2950 модулей), при этом потреблял весьма ощутимую электрическую мощность и грелся как паровоз.

Именно с огромными размерами связано и англоязычное название отладки программного кода — “debugging”. Одна из первых в истории программистов, Грейс Хоппер (да-да, женщина), офицер военно-морских сил, сделала в 1945 году запись в журнале действий после расследования неполадки с программой.

Поскольку moth (мотылек) в общем случае это bug (насекомое), все дальнейшие проблемы и действия по решению персонал докладывал начальству как “debugging” (буквально обезжучивание), то за сбоем программы и ошибкой в коде намертво закрепилось название баг, а отладка стала дебагом.

По мере развития электроники и полупроводниковой электроники в особенности, физические размеры машин стали уменьшаться, а вычислительная мощность, напротив, расти. Но даже в этом случае нельзя было поставить каждому по компьютеру персонально.

“Нет никаких причин, чтобы кто-то захотел держать компьютер у себя дома” — Кен Олсен, основатель DEC, 1977.

В 70е появляется термин мини-компьютер. Помню, что когда впервые прочитал этот термин много лет назад, мне представилось что-то типа нетбука, практически наладонник. Я не мог быть дальше от истины.

Мини — он только по сравнению с огромными машинными залами, но это все еще несколько шкафов с оборудованием ценой в сотни тысяч и миллионы долларов. Однако вычислительная мощность уже возросла настолько, что не всегда была загружена на 100%, и при этом компьютеры начали быть доступны студентам и преподавателям университетов.

И тут пришел ОН! Терминал.

Немногие задумываются над латинскими корнями в английском языке, но именно он принес нам удаленный доступ, как мы знаем его сейчас. Terminus (лат) — конец, граница, цель. Целью Терминатора Т800 была окончить жизнь Джона Коннора. Так же мы знаем, что транспортные станции, на которых производится посадка-высадка пассажиров или погрузка-разгрузка грузов, называются терминалами — конечными целями маршрутов.

Соответственно появилась концепция терминального доступа, и вы можете увидеть самый известный в мире терминал, до сих пор живущий в наших сердцах.

DEC VT100 называется терминалом, поскольку оканчивает информационную линию. Имеет фактически нулевую вычислительную мощность, и его единственная задача — отобразить полученную с большой машины информацию, и передать на машину ввод с клавиатуры. И хотя VT100 физически давно умерли, мы все еще пользуемся ими в полной мере.

Когда шутка ушла в народ и авторство забыто и потерто, но сохранилось в самих шутках. Все началось с перевода первой шутки на русский. Первые 22 - это мои (и нескольких соавторов в чатике) 2012 года. Дальше уже творчество сообщества.

1. Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет.
2. Я знаю отличную шутку про TCP, но если она до вас не дойдет, то я повторю.
3. А кто знает отличную шутку про ARP?
4. А вы слышали шутку про ICMP?
5. Вам еще кто–то рассказывал шутку про STP?
6. Я подожду Антона и расскажу классную шутку про QoS.
7. Про MTU тоже есть кла.
8. <шутка><смешная/><про>XML.
9. А про FSMO роли шутить могут не более пяти человек.
10. Подождите все, я расскажу шутку о сети типа «шина».
11. Я бы рассказал отличную шутку про Token Ring, но сейчас не моя очередь.
12. Стой–стой, послушай сначала шутку о прерываниях.
13. Помню времена, когда шутка про модем пшшшшшшш…
14. Только что, специально для сообщества пришла шутка про мультикаст.
15. Жаль, что шутка про Fault Tolerance не может состоять больше, чем из одного слова.
16. Настало время рассказать шутку про NTP.
17. Я сейчас расскажу отличную шутку про VPN, но ее поймет только один.
18. К шутке про SCTP вначале должны все подготовиться.
19. Из–за одного, кто зевнул, придётся заново рассказывать шутку про frame relay в топологии point–to–multipoint.
20. А шутки про HDLC обычно не понимают те, кто знает другие шутки про HDLC.
21. Про DWDM шутят сразу несколькими голосами.
22. Шутка про Е3 — это 30 одинаковых шуток про Е1 и еще две шутки, понятных только тем, кто в теме.
23. Лучшее в шутках про проприетарные протоколы это УДАЛЕНО.
24. Единственная проблема в шутках про Token Ring в том, что если кто-то начнёт рассказывать шутку пока говорите вы, обе шутки обрываются.
25. Все любят шутки про MitM. Ну, кроме Алисы и Боба, все.
26. идти Самое про BitTorrent — они могут порядке. в шутках лучшее в любом
27. Я бы рассказал шутку про CSRF, если бы ты САМ только что этого не сделал.
28. IGMP шутка; пожалуйста, передай дальше.
29. Нет… Нет ничего… Нет ничего забавного… Нет ничего забавного в шутках… Нет ничего забавного в шутках про определение MTU.
30. PPP шутки всегда рассказываются только между двумя людьми.
31. Шутки шутки про про RAID RAID почти почти всегда всегда избыточны избыточны.
32. Фрагментированные шутки…
33. … всегда рассказываются…
34. … по кусочкам.
35. Вы уже слышали шутку про Jumbo фреймы? Она о–очень длинная.
36. Самое клёвое в шутках про rsync, что вам её рассказывают только если вы не слышали её до этого.
37. Проблема с IPv6 состоит в том, что их трудно вспомнить.
38. DHCP шутки смешны, только если их рассказывает один человек.
39. Жаль, что никто не помнит шутки про IPX.
40. У кого есть кабель? Есть смешная шутка про RS–232 и полусмешная про RS–485.
41. Я сейчас всем расскажу шутку про бродкаст.
42. У меня есть примерно 450 000 шуток про BGP.
43. У кого есть пароли, приходите за шутками про RADIUS.
44. Шутку про 127.0.0.1 каждый может пошутить себе сам.
45. А что, шутки про IPv4 уже закончились?
46. Шутки про RFC1918 можно рассказывать только своим.
47. Шутки про IPv6 плохи тем, что их мало кому можно рассказать.
48. Шутки про SSH–1 и SSH–2 несовместимы между собой.
49. Про Schema Master шутит только один в этом лесу.
49. Шутки про MAC–адрес могут не дойти до тёзок.
50. DNS–сервер не понял шутку про DDoS и ему её стали пересказывать сто тысяч раз в секунду.
51. В шутках про IPSec надо говорить, кому их рассказываешь.
52. И ГОСТ, и ISO согласны, что есть 7 уровней рассказывания шуток.
52.1 Министерство обороны США понимает только четыре уровня шуток.
53. Шутки про шутки про шутки часто звучат в туннелях.
54. Шутки про 10/100/1000BASE–T вряд ли услышат с расстояния больше 100 метров.
55. Шутки про Euclid недостаточно хорошо изучены, чтобы быть понятными.
56. Шутки про Keter █████ ███ ███████.
57. Шутки про Thaumiel сами относятся к классу Thaumiel

На фоне очередных успехов очередного ЦОДа с питанием
+1 история "Ошибки капитального строительства"

Компания организовала 2 ввода, 2 (!) ДГУ, АВР (автоматический ввод резерва). Все по красоте!

Случается инцидент по питанию - всё ложится, питания нет.

А разгадка одна:

2 ввода, АВР - они только на входе. Раз у нас все хорошо и резервировано, то после АВРа в машзал идет один луч питания с одним автоматом.
Этот автомат и сгорел.

На злобу непогоды дня.
+1 история "Ошибки капитального строительства"

"Жила была одна компания, которой досталось здание то ли от ночного клуба, то ли от сауны, то ли от того и другого вместе. Компания не занималась ничем вышеупомянутым, так что пришлось приспосабливать помещения под обычную офисную деятельность.
И был там бассейн, в котором уже давно никто не плескался. Долго ли, коротко ли, но решили этот бассейн использовать под серверную, а прямо в чашу бассейна стойки и поставили.

Водопровод, разумеется, перекрыли. Да вот случилась непогода сильная, лютая. Затопило все ливнёвки и канализацию. И оказалось, что водопровод то в бассейне перекрыли, а вот слив в канализацию нет.
И организовалось стихийное жидкостное охлаждение иммерсионное прямо для всего серверного хозяйства. С понятным результатом."

Это не может быть DNS!

Если у вас происходит необъяснимая фигня в сети, не поддающаяся логике. Если соединения то проходят, то не проходят. Если соединения идут, но не все.
Есть ровно один главный кандидат - DNS. И два его подручных - BGP и DHCP.

Давайте поговорим о диагностике участия DNS. Я в очередной раз потратил три дня на раскопки и разборки с системным ПО из-за DNS, поэтому будет и мне напоминанием. Все приведенные кейсы реальны.

1. Кейс об отсутствующих DC/DNS

В системе VDI происходит длительный логин, иногда до 30 секунд ожидания. Все бы ничего, но в ней работает от силы 30 пользователей.

Причина - исторически сложилось, что в терминальном брокере были прописаны DNS3, DNS2 (совмещенная роль AD/DNS), но по ходу эксплуатации DNS3 остался резервным и перешли на DNS1, DNS2. И при очередных работах DNS3 просто забыли включить назад. Сменили на брокере DNS на актуальные - логин стал моментальным.

2. Кейс о нестабильном сетевом коннекте.

Сервер приложений то отвечает, то не отвечает. Любые корреляции случайны, включая фазы луны. Обращение в ТП сервера приложений стало просто анекдотичным.

- Пришлите нам tcpdump
- Вот, смотрите - запрос есть, ответа нет
- А вот смотрите у нас в лабе есть запрос и есть ответ.

- Алло, пожарные, у меня 9-этажка напротив горит!
- Да? А у меня напротив такая ж 9-этажка и не горит.

Технологический ландшафт. В конторе две технических службы, одна из которых классические офисные ИТ, а вторая тоже ИТ, но не офисная от слова совсем. Сервер приложений в ведении ИТ2, и у ИТ2 даже свой собственный сетевой сегмент, свои серверы и даже маленький технологический домен с собственными DNS.
На серверах DNS ИТ2 стоит безусловный форвард на DNS ИТ1 всех неизвестных запросов.

Причина. Сервер приложений по какой-то неизвестной причине обязательно делал реверс-DNS запрос по каждому клиенту. Поскольку обращение к серверу приложений в технологической зоне шло с офисной машины администратора, то реверс-запрос сразу форвардился на DNS ИТ1, а там на одном из трех DNS были в наличии не все реверс-зоны.

Потеряно 3 недели и целая куча нервов во взаимных обвинениях между ИТ1, ИТ2 и разработчиком сервера приложений.

3. Кейс о машинах VDI, которые то добавляются, то не добавляются

Администратор создает VDI машины и добавляет их в пул. Но иногда случается ситуация, что машина добавляется на пол-шишечки. Т.е. все всех видят, стабильная сетевая связность, но агент не может соединиться с брокером. При этом сетевая связность машины (на которой агент) с сервером (на котором брокер) есть и безупречная - 25 Gbit один хоп.

Причина. Машины VDI находятся в зоне технологической лаборатории и бывает так, что в DNS остались записи на тот же IP, а часть записей никто не вносил. Судя по всему, снюхивание агента с брокером зависит от DNS и в частности реверс-DNS, поэтому очистка DNS от лишнего и прописывание прямых и обратных адресов сработала.

Итоговая методичка по проверке DNS
1. Нарисуй структуру всех участвующих DNS и кто кому форвардит
2. Разбей DNS на группы, и напиши какие группы отвечают за какие зоны
3. Проверь, что репликация зон настроена на всех DNS из каждой группы
4. Проверь, что на всех DNS есть все зоны, включая обратные зоны
5. Проверь, что нет лишних записей с теми же адресами
6. Проверь, что все адреса внесены в DNS, включая обратные зоны

🔥 Интерактивный ProIT Fest V 5-6 июля, где IT-профи создают контент вместе с вами: баттлы, игровые форматы, мастер-классы, споры, живые дискуссии и даже стендапы!

✔ Интересное в программе для DevOps/SRE:

➡ Конечно же я) Расскажу про Контр-интуитивное проектирование

➡ ФинОпс - что это такое и как это организовать Гальцев Игорь Технический директор Клаудмастер

➡ Круглый стол: «Доавтоматизировались»
Павел Селиванов Yandex Cloud, руководитель продуктового направления DevOps Tools, Иванов Алексей, 2ГИС QA Automation Engineer, Вадим Утратенко.

➡ От «Давайте запланируем доставку карты» до «На какой сервер deploy?» Маша Цирители - Руководитель направления разработки, Т-Банк

➡ Круглый стол: «Базовая гигиена» Дмитрий Тихонов - ведущий инженер DevOps, Т1, Роман Корчагин - DevSecOps, Лаборатория Числитель, Антон Быстров - SRE техдид Cloud.ru

➡ Стендап: «Это не продакшн-хаос. Это распределённая система страданий» Антон Егорушков Head of DevOps Lamoda Tech

➡ В секции Fight коллеги Андрей Сухоруков Team Lead DevOps/SRE/DevSecOps Лаборатории Касперского и Андрей Синицын Руководитель платформенного отдела в Ozon устроят баттл, но не по техничке, а по наболевшей теме «No blame culture, как болезнь лжи в организациях»

➡ А в секции Standup вас ждет Стендап: «DevOps - это любовь» Александр Чистяков, многодетный отец девопсов, Александр Крылов организатор DevOpsForLove, CPO штурвала в Лаборатории числитель.

⚡ А также вас ждет множество холиварных тем, суд техлида над тимлидом, прокачка management и soft skills, и даже практика английского с Native Speaker ex. Microsoft, скрывающегося в Росcии

📆 Полную программу смотрите на сайте.

PRO IT Fest V
5–6 июля
Санкт-Петербург, пр. Медиков, 3, корп. 5
Конгресс-центр «Ленполиграфмаш»

Билеты
Наш телеграмм канал, где мы рассказываем о фестивале
Промокод на 20%: beerpanda

Один заказчик устроил серверную в самом защищенном помещении - бывшей оружейной комнате. Стены 1м толщиной, мощная дверь. Кондиционера нет - слишком трудно и дорого. В результате - дверь в серверную была всегда открыта, рядом колхоз направленного охлаждения.

+1 история в "Ошибки капитального строительства как фактор ИБ"

Неделю назад легла зона в Я.Облаке. Специально подождал пока утихнут страсти и мнения, и будет понятно что случилось.

Кратко. Легло питание.

У всех корпоративных инфраструктурщиков сразу вопрос - а что, ДГУ не запустились?

- Пэйн, я ДГУ не вижу!
- А их и нет!

ДГУ в проекте даже не были предусмотрены. И нет, это не ошибка, это вполне взвешенное решение от проектировщиков Я.Облака.

Много лет я вижу что на конференциях, что у заказчиков, тему от облачных провайдеров "да зачем вам свое ИТ, приходите к нам, у нас железо, ЦОДы и спецы."
И следом ррраз - коммерческое предложение с очень привлекательной ценой в месяц против каких то чудовищных сотен миллионов или даже миллиардов рублей за собственный онпрем ЦОД.

И вот здесь и кроется интересный момент в сравнении.

Онпрем можно построить с любой заданной степенью надежности, математически доказанной. Нужна устойчивость от катастроф - построим метрокластер, репликацию, что угодно. Да, это стоит денег, это часто очень дорого. Но при этом с минимальными, а то и вообще без изменений ландшафта ПО. Это инфраструктурный проект, почти не затрагивающий прикладной слой.
Мы поставим ИБП, ДГУ, лазерную связь, спутниковую - все это может быть реализовано в онпрем, если ведет к снижению простоев и потерь данных. Но дорого и очень много капитальных затрат + сроки реализации.

Облако очень удобно, минимальные стартовые затраты, оплата по факту, ничего строить не надо, доступно сразу.
Облако надежнее и лучше пока нет своей инфраструктуры и инфраструктурщиков, а есть только пара-тройка гениальных программистов в стартапе.

Но по мере роста сложности и объемов бизнеса начинают вставать вопросы надежности. И здесь мы упираемся в термины "оферта" и "SLA", а конкретно уровня штрафных санкций за нарушение SLA.
Если в онпреме мы строим инфраструктуру, не ограничивая уровень ответственности, а считая прямые убытки от простоев / потери данных, то облаку все это не требуется. Все это ограничено 15-30%, ну пусть даже 100% (что почти нереально) одного месячного платежа. И соответственно нет никакого резона строить инфраструктуру облака, которая будет дороже, чем возможные штрафные санкции в виде скидки размером в месячный платеж.
И вот тут мы и приходим к вопросу почему у Я.Облака ДГУ просто нет в проекте. А есть вероятности выхода из строя питающих подстанций и стоимость простоя при маловероятном выходе из строя сразу двух. Матожидание, если в терминах теории вероятности. Стоимость ДГУ попросту кратно превышает ответственность, поэтому ДГУ там не нужны.

Как же тогда обеспечивать надежность? О, ну тут просто - вы просто берете и переписываете весь прикладной слой, чтобы он работал в двух, трех зонах доступности в асинхронном режиме. Ведь между зонами сеть не позволяет делать метрокластеры и работать синхронно, слишком разнесены зоны географически.
А в момент переписывания вы разумеется берете значимое количество "managed" сервисов облака. Зачем брать только ресурсы и строить все балансировщики, БД, хранение? Берем их в готовом виде и строимся уже не в IaaS, а в PaaS. В нескольких зонах. И живем, все у нас прекрасно.

Пока не захотим съехать в другое облако или даже в онпрем. Почему мы же мы можем захотеть съехать в онпрем?
1. Мы слишком выросли, своя инфраструктура становится в разы дешевле облака.
- Пример Dropbox. 100% выросший в AWS был вынужден не то что инфраструктуру свою строить, а начать покупать магистральных провайдеров. Слишком вырос трафик и популярность.
2. Требования регулятора, опасность полит. плана.
- Пример AWS vs Parler.
3. и еще много вариантов

Ключевой момент. Облако - это не про технологическое лидерство, это про как максимально сэкономить и снизить стоимость MHz, GB RAM, TB хранения, чтобы перепродать дороже. Вплоть до отказов от ДГУ и вообще резервирования, если это поможет продаваться.
И если у вас нет своих инфраструктурщиков, которые будут понимать как и где может развалиться ваша виртуальная облачная инфраструктура, и знающих как построена физика внизу, чтобы вовремя вас предостеречь - может быть мучительно больно.

Как защититься от шифровальщиков?

Есть много превентивных мер, есть предложения, схемы. Которые в разной степени дороги, успешны.
Но в основном понимается как превентивный подход - т.е. как не дать шифровальщику пробраться и наделать делов.

Это очень важно, ни в коем случае не отрицаю. НО!
Значительно важнее, а самое главное проще, дешевле и надежнее СНАЧАЛА реализовать вариант устойчивости к шифровальщику, который уже пробрался и нашифровал.

1. Схема резервного копирования с регулярным дублированием копий на отчуждаемые носители, лежащие в сейфе.

Нельзя зашифровать только те данные, которые не подключены в сеть. Исходя из этого ваш RPO равен промежутку между выкладыванием лент в сейф. Если ленты остались в библиотеке - они могут быть зашифрованы или испорчены.

2. Особо ценные данные размещать на СХД корп класса с поддержкой дискового журналирования класса EMC RecoverPoint (да-да, я знаю что он мертв), или снапшоты раз в 15-30 минут для снижения RPO


Конечно, лучше бы не допускать шифровальщиков, но делать упор на перевентивные меры, отрицая СРК?
Если вы пропустите угрозу, то при бэкапах вы можете восстановить. А без них закрывайте компанию
Это как отрицать антибиотики потому что пьешь витамины и руки моешь

"Тогда надо включать пункт про криптокошелек - держу 10K$ и больше в битке для оплаты на ключи шифрования )))) таких кто платил видел лично"

It depends. Если у вас политически (по решению СБ и руководства) разрешены переговоры с террористами (авторы и распространители шифровальщиков = террористы) и вы готовы их прикормить, то да, для вас это просто расходы.
Правда есть нюанс, что не расшифруют.

"Надо следовать правилу 3-2-1"

3-2-1 как любой бестпрактис - лучше, чем ничего вообще.
Но не надо в него упираться. Иногда есть варианты лучше и правильнее для конкретного кейса.

Любой бестпрактис надо осознать, положить в контекст, в том числе исторический. И понять попадает ли ваш кейс по угрозам в модель угроз, для которой написан этот бестпрактис.

И даже в этом случае сделать возможность бэкапа на отчуждаемые носители мало. Необходимо внедрить это в процесс и вовлечь СБ в контроль, потому как иначе на все будет забито.
При этом обязательно нужен план восстановления, детальным и пошаговый, чтоб когда придет время, админы смогли его взять и выполнить.
Причем пошаговым прямо в расчете на то, что его придется выполнять в 4 утра первого января пьяному и очень нервному инженеру

В обязательно же порядке добавляем тестирование РК и внешних (отчуждаемых) носителей.
И тестируем не только носитель, а весь процесс восстановления.

Есть прохладная история из асашайки.

Была контора, где внедрен был процесс РК на лентах, которые отвозили в архив на аутсорсе (Iron Mountain). И вдруг бац, надо восстановиться.

Съездили за лентами, восстанавливаются из лент- ан хрен, полная копия (понедельник) запорота. Отправили за недельными лентами.
Та же история.
В итоге потеряли данные за 4 месяца.

Начали выяснять. Оказалось, что вообще то ленты в архив возит один и тот же мужик. Но 4 месяца назад у него то ли жена родила, то ли что то семейное случилось и теперь он по понедельникам должен отвозить детей в школу и договорился, что в понедельник ленты отвозит другой дядька.

Дядька нормальный, ни в чем не замечен, злого умысла никто не нашел. Пошли уже прям досконально - давай показывай как ты едешь, везешь.

Показывает. Подходит к машине, кидает ленту в багажник.
А там у него ИПИЧЕСКОГО размера сабвуфер!

DevOps Meetup в Москве 27.03

Расскажу про то, как можно облажаться в самом нижнем уровне стека, на уровне бетона и арматуры.

27 марта мы снова встречаемся в Москве с компанией Островок! и DevOps community!
Поговорим о серьезном со смехом:

🎙Ведущие:
- Александр Крылов организатор DevOpsForLove, CPO штурвала в Лаборатории числитель
- Денис Божок Engineering manager Островок!
- Анна Афонина организатор ProIT Fest

Спикеры:
🟢 «Процедура как готовится к работам связанными с даунтаймами», Иван Иостман, Senior Data Infrastructure Engineer, Островок!

🟢 Standup «Девопс не лошадь» Александр Чистяков, многодетный отец девопсов.

🟢 «Автоскейлинг инференса в Kubernetes» Антон Алексеев Selectel

🟢 Standup «Ошибки капитального строительства» Антон Жбанков

И конечно нас ждет after party в Баре!

Мотивация встать с дивана: классная локация, вкусно, крутые эксперты и подарки от Островка.

❓Для DevOps из других городов, и тех, кто не сможет добраться в оффлайн, через 2 недели мы можем выслать видео митапа на почту, указанную в регистрации, для вас там есть отдельное поле. Трансляции не будет.

👉Регистрация тут. Эта встреча только для DevOps. Регистрация на мероприятие одобряется вручную в течении 1-2 дней. После подтверждения к вам на почту придет уведомление.

🔎 Закулисье IT-проектов: почему некоторые проекты терпят крах ещё до начала?

Специальная площадка «Как провалить ИТ-проект, не написав ни строчки кода» — это уникальная возможность заглянуть за кулисы реальных кейсов и ошибок, о которых обычно принято молчать.

На площадке выступят опытные архитекторы и DevOps-эксперты, которые поделятся уникальным опытом:

🔜 Антон Жбанков — ведущий архитектор по вычислительной архитектуре, независимый эксперт

Тема выступления: «Контр-интуитивное проектирование ИТ-систем»

🔜 Ростислав Глузман — консультант, Ex старший тех. менеджер Yandex / руководитель направления Сбер / ведущий архитектор ВТБ&МТС

Тема выступления: «Как провалить проект по Agile и ничего не понять»

🔜 Константин Жебенев — предприниматель, консультант по ИТ и ИБ, советник генерального директора АО НИИ "Масштаб"

Тема выступления: «DevSecxOops! I did it again или как не кончить преждевременно свою ИТ-карьеру»

🔜 Вадим Подольный — руководитель комитета промышленной автоматизации АРПП "Отечественный софт", автор книги "Архитектура Высоконагруженных Систем"

Тема выступления: «Как навязанные некомпетентные коллеги могут сделать вас незавершенцем»

🔷Почему стоит посетить?
Крутая возможность на примере опыта профессионалов узнать, как остаться на вершине, несмотря на ошибки и провалы.

📌Чтобы посетить площадку, необходимо зарегистрироваться по ссылке.

Что мешает корпоратам продавать внутренний софт на внешнем рынке?

Многие компании, включая Сбер, активно разрабатывают собственное программное обеспечение.
Однако возникает вопрос: что мешает продавать это программное обеспечение на внешнем рынке?

Возник в обсуждении следующий вопрос.

Итак, что же мешает?

1. Необходимость набирать дополнительные команды по упаковке ПО, бизнес аналитике, поддержке, маркетингу, сейлов...
2. Безопасность как процессы и департамент
3. Внутренняя разработка должна быть вынесена во внешний контур. Но при этом должна быть сохранена связь - чтобы ПО заносилось внутрь и весь документооборот, тестовые стенды, тестовые данные. Снова вопрос безопасности и процессов.

Получается затратно и не выгодно для организации организовать продажу своего ПО.

Да, затратно.

Выгодно или не выгодно - ответа быть не может до проработки аналитиками и маркетингом.
Может это суперуникальный софт, идеально подходящий под именно эту контору с именно ее сложившейся исторически структурой. Шаг вправо - шаг влево и все, под переписывание с нуля.

Если взять бизнес-софт, разработанный условным Сбером - кому его продавать? Много ли вообще покупателей найдется на такой софт, с учетом разницы калибров?

А если взять такой же софт, разработанный банком из "топ 397", то что с ним должен делать условный Сбер со своими оборотами и количеством транзакций в день?
Уверены ли вы, что банк из "топ 397" архитектурно заложил уровни нагрузки, защиты, обеспечил соответствующее тестирование, чтобы Сбер взял и купил его вместо написания своего?

Но софт может быть не заточен по инфраструктуру, по направлениям к примеру: редактировать текст, работа с видео, работа со звуком, распознавание текста со скана и т.д.- то что можно установить на ноутбук или на рабочую станцию.

Т.е. вы считаете, что банкам и прочим крупным ИТ конторам нечем заняться, поэтому внутренняя ИТ разработка занимается очередным текстовым редактором (1002м на рынке), пишет обработку видео (монтаж и прочеее), и вообще занимается универсальным пользовательским софтом, вместо того, чтобы взять с рынка или из опенсорса готовую софтину?

Предположим какие то пересечения есть. Можно даже что то найти.

Итого:
1. Организовывается спец отдел для аудита всего кода и всей разработки - что вообще в принципе можно отдать
2. Организовывается особый отдел по очистке внутренней разработки, которая никогда не планировалась на открытый рынок
3. Еще один комитет по принятию решений
4. Потом еще один комитет по интеллектуальной собственности
5. комитет по принятию решений по безопасности - можно ли вообще это отдавать

Это ФОТ, время, найм, работа.

После Х затрат решения приняты.

Код готов к выдаче командам, которые займутся разработкой на открытый рынок (а где они, мы же их не наняли).

Или организуется НИИ "СпецКодХран", в который все *Банки, *Ойлы и остальные начинают сгружать этот код?
А кто его дальше двигает в универсальную среду, чтобы он начал развиваться?

А что делает *Ойл, сгрузивший очищенный код? Замораживает кодовую базу и ждет пока НИИ СКХ выпустит релиз? А что если НИИ СКХ делает это слишком медленно или развивает продукт не в ту сторону? Должен ли *Ойл менять свои бизнес процессы под роадмап НИИ СКХ?

Конечно нужен аудит, что есть на рынке, и что ждёт государство от ит в качестве #ракетаИмпортозамещения

А кто аудит делает-то? НИИ СпецКодПоиск? Тогда как они получают доступ к закрытой информации и ком тайне?
Собственными силами?

Итого, что мешает продавать внутренний ИТ продукт на рынке?

Ответ: это непрофильный бизнес для абсолютного большинства. Перевод продуктов из внутренних во внешние - это организация нового непрофильного ДЗО с туманными перспективами в ситуации острой нехватки кадров.

Какая связь между World of Tanks и переменными окружения?

А точнее, знаете ли вы на самом деле зависимости и ограничения своего или чужого софта, который применяете у себя?

Вот есть игрушка "Танки", которую пишут разработчики, а помогают им девопсы и все модные и красивые, клауд-нейтив ололо.
Но весь клауд-нейтив ломается на древней как мир вещи - на переменных окружения, хотя казалось бы где Танки и досовские (консольные) переменные?

Оказывается, что в новой модной игрушке где-то глубоко зашита древняя (в смысле заслуженная) утилита curl, которая видит ваши переменные окружения, и в частности http_proxy, и если таковая есть - лезет в интернет через этот прокси. Вне зависимости от того, есть в настройках самой игры подключение через прокси или прямое. В итоге если у вас на десктопе по какой то причине есть специфическая конфигурация сети, чтобы разный софт в интернет ходил по-разному, то нет, не получится поиграть. Танки не запустятся, если этот curl не сможет проломиться через этот http_proxy.
Разработчики Танков решили не заморачиваться нативными способами доставки контента в единой сетевой модели - они просто обернули curl.
Потому что ну вы знаете - так в примерах показано, чего там уж париться?

И это простой пример. А сколько у вас таких примеров и копи-пасты кода пораспихано по проду? Знаете ли вы все зависимости и требования своего софта?
Сколько кода у вас вообще подсасывается из гитхаба при сборке, а не хранится в локальных репозиториях?