Сейчас да, я полностью соглашусь. Тогда, когда я только пробовал свою первую Raspberry Pi, задача стояла не в том ключе, чтобы разориться на покупку nvme, а попробовать вообще подойдёт малинка для тогдашних моих нужд или нет. Возможно да, это бы решило проблему UBOOT и расширило бы выбор OS, но сейчас меня итак устраивает и без лишних трат. Малинка прекрасно работает как backup-платформа, на которой можно даже что-то запустить с минимумом энергозатрат.
проделано многонедельные работы, но зачем?
Ради результата. Сейчас у меня два ёмких диска на двух сторонах и я ничем не ограничен в своих желаниях хранить любой объём интересующих меня данных; синхронизация с проверкой и полная уверенность в идентичности данных; прямой доступ к данным через обе железки — к обеим точкам я могу за считанные секунды подключиться через интернет и добраться до любого файла.
Несомненно, HDD не конкуренты NVME дискам. И вообще магнитная технология заведомо обречена на увядание. Однако обещания Samsung выпустить четыре года назад NVME диски пользовательского уровня ёмкостью 100Tb пока так и остаются обещаниями. Учитывая ≅6 кратную разницу в стоимости хранения одного мегабайта продолжаем жить с HDD и жать светлого будущего.
забыть о многонедельных попытках восстановления
NVME точно так же НЕ гарантируют 100% сохранности и доступности данных как и HDD. Рано или поздно, но и с любыми solid state возникнут проблемы. Даже солидных брендов. Технология увы, не совершенна. Это не просто слова, это неоднократный личный опыт.
Перед ответом я тщательно подумал над Вашим так точно заданным вопросом! И да, совершенно верно, была бы опция прерывания, — не было бы статьи, не было бы и моего личного опыта в борьбе с несовершенством цифровой реальности.
Но! На самом деле я рад этому опыту! Есть такой термин, часто используемый в разработке: Test Oracle — тестовый Оракул. Это некая независимая сущность, призываемая для проверки результата.
Ещё тогда, когда я уже начал использовать rsync для рабочих нужд, не до конца понимая всех нюансов его работы, я интуитивно чувствовал, что использовании единственного инструмента может таить угрозу. И потом, внезапно потеряв кусок важного дампа БД в DRC банка я в этом убедился воочию. Пришлось вникать в нюансы и строить процедуры периодического восстановления из бэкапов на архитектуре DRC. Это было чертовски сложно и долго, но действительно гарантировало восстановление работы на резервных ресурсах в случае проблем с основным DC. Это и был тот самый Оракул, который проверял результат.
precizer в данном случае тоже является оракулом, связанным с основным инструментом синхронизации, только через данные. Простым, но от этого не менее эффективным.
Угрозы могут идти не только от rsync. ПО или железо. Развалившийся RAID, проблемы с бэдблоками на дисках в более простых решениях, сбои на сетевом уровне, баги в ПО: как внутри rsync, так и в любом другом. Всё это несёт реальную угрозу рассинхронизации.
После наступания на «грабли» я теперь осознаю важность тестового Оракула. Не precizer, так какой-то другой инструмент. Поэтому все мои текущие и будущие решения в обязательном порядке будут построены на этом принципе.
От души благодарю. Значит не зря старался! Думаю, в будущем больше никто так не будет писать не потому, что весь мой айтишный опыт — продукт того самого диалапа, времён абсолютной свободы фидо, субкультуры udaff и padonkaf, а потому, что все ленятся и получается юридически выверенный, стерильный текст, выс…ый AI. Ну хорошо, может не ленятся, но экономят личный невозобновляемый ресурс — время.
Меня когда то сильно впечатлил стиль текстов Andy Weir: добрый, умный, сложный и с циничным юмором. Наверно, это теперь неосознанно отражается в том, к чему сам стремлюсь.
Сейчас вспоминаю и с удивлением осознаю, что раньше можно было писать обо всём и на любую тему, и за это тебе ничего не было (кроме злобных модераторов, которые могли кенсельнуть пост, конечно! :)
А теперь каждый телефон о тебе докладывает куда нужно и там где нужно знают о тебе больше, чем ты сам.
Хоть сейчас трава за моим окном и зеленее, чем была раньше за моим другим окном в прошлой жизни, но всё равно, поразительные и удивительные были времена! :-D
syncthing
Моё первое знакомство с этим решением состоялось несколько лет назад, когда я пытался отправить родственнику через полпланеты огромный архив со словарями Goldendict и их индексацией. Тогда это казалось восхитительной идеей: и тебе торрент-протокол, и шифрование, и контрольные суммы и докачка. По-факту промучались неделю с нулевым результатом и пришлось искать альтернативные пути. Это при том что между нами нет ни каких DPI или какой-либо другой дряни, которая могла бы потенциально помешать передаче.
Потом была ещё одна попытка завернуть трафик syncthing в туннель или любой VPN и тоже безуспешно — эксперименты остановились на стадии исследования. Цель полностью недостижима архитектурно, несмотря на заверения нескольких источников в обратном.
Идеи заложены правильные, но тратить время на это кривое поделие я больше не хочу. Может быть, когда-нибудь, напишут на хорошем языке программирования что-то в таком же стиле, но действительно работающее. Но это будет уже не syncthing.
rsync не идеален, но он работает. Он полностью надёжен и предсказуем. Не вижу смысла менять что-то архитектурно, что уже проверено годами. Улучшить — да, можно. И статья именно об этом.
Мой опыт ограничивается только замерами на паре вариантов несильно старых x86_64 CPU, поэтому да, возможно мои выводы были поспешны. Спасибо за точку зрения!
Моё личное наблюдение — sha512sum работает быстрее, чем sha256sum
К предложенной схеме с find/rs/sort/diff есть несколько вопросов:
Если мне хочется проигнорировать директорию с сериалами, которые я вообще не бэкапирую и которые занимают половину диска? А если список для игнорирования состоит из трёх десятков пунктов? Лично в моём случае так и есть для rsync — передаю их параметрами в скрипте резервирования.
Что если мне нужно продолжить с прерванного места?
Что в плане обновлений через месяц, например, чтобы актуализировать все изменения после бэкапа? Перерасчёт с нуля всех 25Tb?
Вопросы не праздные — я в них упёрся в тот момент, когда сам продумывал решение и хотел нагородить проверку контрольных сумм на bash скриптах и системных утилитах. Думал, что ничего сложного нет.
там суммы считаются/проверяются во все потоки
Каким алгоритмом рассчитываются суммы? Это алгоритм с поддержкой многопоточности или под многопоточностью подразумевается обращение к диску в несколько потоков для чтения файлов? Просто интересуюсь.
Хотел бы как автор статьи написать ответ. Как мне показалось, Ваш комментарий был именно адресный. С одной стороны Вы во всём правы, ничего такого в DevOps неправильного нет. Всё разумно, логично, взаимосвязано и абсолютно последовательно соблюдаются все причинно следственные связи. Но…
Лень идти читать, но думаю той же посторе и мускулу уже не 5 и не 10 лет.
Если бы только ограничивалось постгрёй и мускелем. Ан нет… Это вообще не из сферы DevOps. Там этого не достаточно. Им подавай Aurora, DynamoDB, DocumentDB, Keyspaces, Neptune, Timestream LiveAnalytics, Redshift, RDS (отдельный зоопарк), ElastiCache, MemoryDB, OpenSearch Service и это только стэк Amazon Web Services и только в сфере БД. Перечислить зоопарк остальных вендоров? Не? Хватит?
Не лень. Просто реально ни времени ни оперативы держать в голове весь этот бардак не хватает просто биологически. Слишком много информации и слишком ко́роток срок жизни этих технологий. Думаю через 10 лет даже половины из перечисленного списка либо не будет уже существовать вообще, либо они трансформируются во что-то совершенно другое.
такого нытья
Тут много раз в комментариях уже упоминался именно этот термин. И да, нельзя не согласиться с целесообразностью его использования. Статья действительно получилась уж сильно эмоциональной, очень “соль на рану” и по-живому. Потому что тогда рана действительно была и она здорово припекала. Новые поиски работы, новые сомнения, моральные страдания и то чувство, когда ощущаешь себя ничтожеством среди мэтров своего дела на очередном собесе, на котором тебя носом тычут в новые технологии и недоумевают как такие “элементарные” вещи можно не знать.
Не знаю их и больше знать не хочу! Вот честно!
Сколько прошло с тех времён? Год? Полтора? Только что прокрутил до даты создания статьи. Нда… Потрясно… Два года уже прошло! За два года эмоции поутихли, но лично моё мнение сформировалось надёжно и наверно уже навсегда. Сейчас можно честно признавать, что в статье больше эмоций чем объективной оценки средней температуры по палате. За что статью не раз критиковали (обосновано) в комментариях. Которые сами нередко были предельно эмоциональны… Ну да ладно… Мы все люди а не роботы, у нас есть чувства, эмоции и не только умом и холодным расчётом формируется наша жизнь и профессиональные предпочтения.
Пару лет назад я сделал выбор и надо сказать что очень удачный. Сейчас меня устраивает буквально всё. AI убрал из программирования ту тупую рутину печатания, которая многих вводила в уныние. Лично я просто в восторге от процесса кодинга с агентами! Чувствую себя художником, а не “машинисткой” печатной машинки, вынужденной к тому же угадывать синтаксис разыменования указателей. В моей жизни теперь много Си и на работе и как хобби и я ну ни капли не жалею о таком радикальном развороте моей профессиональной карьеры, к которому я упорно шёл сквозь годы. Я расту и совершенствуюсь в этом ЯП. Да, он сложный и даже после долгих лет работы открываешь для себя много нового снова и снова. Особенно, когда есть AI у которого можно получить разъяснения, а не так как раньше: ждёшь ответа неделями, но так и не получаешь. Потому что профи либо заняты, либо лень, а остальные 99,99999% прочитавших вопрос просто не знают на него ответа.
Чего в моей жизни больше нет или что улучшилось за это время:
Теперь я сплю крепко даже тогда, когда условно “дежурный” на телефоне (как разработчик). Я далеко не первая линия обороны между конечными потребителями и продуктом который пишу и за всё это время ни разу меня не побеспокоили именно по поводу проблем с ним связанным.
Нет тех тревог, которые были из-за уровня ответственности за продакшн и проблем связанных с многослойностью технологий, когда на каждом этапе что-то может пойти не так и всё — конец покою и кроме тебя, девопса и виноватых-то больше найти не получится!
Я отвечаю только за ОДНУ(!) софтину которую пишу, а не за тот зоопарк технологий наговнокоженный абы-как и кем попало под громкими брендами типа Amazon или Oracle. Если отвалилась из сети пачка серверов с моей софтиной, то кто виноват? Правильно — кто угодно, но не я. Моя софтина как выключатель: либо работает, либо нет — тут всё просто. А кто отвечает за всё остальное? Маршрутизация, внутренняя сеть, железо, виртуализация, кластеризация, контейнеризация, операционки, обновления, ядра, драйверы? Правильно: команда тех самых девопс-инженеров, мечтающая выспаться хоть разочек. Мне остаётся только утром вместо новостей с чашкой кофе читать сводки по сбоям (так… по-диагонали пробежаться, чтобы понять затрагивает это мой сектор или нет).
Все это развивается, но…
Вот всё на первый взгляд в DevOps логично и правильно:
Виртуализация — это совершенно логичный шаг в попытке рационально уплотнить использование софта на очень быстро эволюционирующем железе.
Контейнеризация — такой же логичный шаг в направлении развития деплоймента, миграции, отказоустойчивости, изоляции и версионирования.
IaC — абсолютно разумная технология в попытке навести порядок и управлять сотнями и тысячами единиц ресурсов.
Но всё это логично и правильно только на первый взгляд. По факту, все эти красивости состоят из стянутых кое-как и склеенных соплями в пучок сотен тысяч программно-аппаратных компонентов разных производителей и у разных поставщиков услуг (библиотеки, комплексные программы, чипы, прошивки, операционки, ядра, драйверы устройств) в которых есть миллионы своих мелких или крупные багов и скрытых проблем. И DevOps не только не контролирует ни одну из этих миллионов скрытых проблем, он даже не подозревает об их существовании, потому что инженер управляет сущностями на совершенно другом уровне абстракции.
Приведу простой пример: терраформ работал-работал и вдруг перестали выставлять проперти на s3 бакет. Один долбаный бакет! Накатываем - откатывается. Каждый этап — полчаса. Бьёмся день. Где баг? В конфиге этого бакета, который не менялся уже как год? Через что-то другое задели, потому что настройки пропертей шарятся среди десятков других сториджей? В день делается с десяток изменений командой из нескольких человек. Кто поломал? Откат гитом всей конфигурации на сутки назад: тот же результат — не можем накатить вообще никаких изменений из-за этого одного бакета. Выставляем проперти вручную — всё работает. Неделя в попытках разобраться спускается в унитаз и под занавес — проблема исчезает сама собой. В анонсах AWS - ни слова ни о баге ни о его ремонте. Неделя отравленного времени, настроения, скандалов и бессонницы, обвинения от кого угодно в некомпетентности и даже саботаже на всех уровнях руководства. Всё это — банальный график ежедневной работы рядового DevOps инженера. Надо оно лично мне? О нет! Уверен — не хочу во всё это окунаться больше ни разу, даже если мне при этом будут подавать ключи (как в том анекдоте).
Одна из тех причин почему выбор пал именно на Си, это самодостаточность. Программе на Си не нужны виртуальные движки как Java, PHP или NodeJS с их версионностью, багами, деприкейтами и legacy, не нужны кеширующие прекомпиляторы и другие костыли. Не нужны зависимости, зависящие от зависимых зависимостей в которых постоянно находят чужие интружены (сорян, каламбур сам по себе напрашивался, навеянный dependencies в NodeJS и проблемами с ними связанными).
В Си тоже широко используются библиотеки, но это не разрушает самодостаточности. Чем выше самодостаточность — тем меньше потенциальных точек отказа, тем выше стабильность, предсказуемость и контролируемость. То, чего мне не хватало в DevOps — ощущения стабильности, предсказуемости и контроля, я в гораздо большей степени нашёл в Си-разработке.
На работе у меня код, который писался в течение 35 лет и насчитывает около 170 000 строк. Сложный, стабильный и с нулевым покрытием юнит-тестами (тогда TDD был не в фаворе) К тому же, код изначально писался и развивался под AIX (была такая OS, а может и есть до сих пор) которая, кстати, big-endian с нативной кодировкой EBCDIC вместо привычной нам ASCII. И что? И ничего! За пару месяцев весь этот код без особых последствий силами двух очень хорошо разбирающихся программистов портировали на Linux x86_64 который уже little-endian. Теперь софт продолжает успешно трудиться на фундаментально другом железе, другой операционке и собранный абсолютно другим компилятором.
В чём тут принципиальное отличие от философии DevOps? Нет лишних слоёв абстракций! Всё максимально просто, поэтому надёжно как до сих пор работающий лом, доставшийся в наследство от прадедушки вместе с сарайчиком, в котором стоят пластиковые китайские грабли, гнущиеся в нужных и, главное, в ненужных местах на все 180 градусов, как современные облачные технологии, прогибающиеся под прихоти в самые замысловатые позы.
DevOps как набор идей логичен. Но конкретная работа DevOps-инженера во многих компаниях превращается в жизнь на стыке чужих абстракций, чужих багов, чужих API, чужих бизнес-решений и твоей персональной ответственности. Лично мне этот тип нагрузки оказался разрушителен.
Кто-то вообще пишет веб на Си??
Пишет! :-D
Даже фреймворки есть, чтобы не приходилось мудрить на примитивном уровне с printf(“%s”,"<html "); и даже их несколько. Прекрасно себе живут и пользуются популярностью, потому что софт на их базе потребляет в 10-20 раз меньше ресурсов по сравнению аналогичными решениями на других ЯП. Там где под Java web-приложение нужно 20 серверов под такую же логику программе на Си потребуется только два. Не всегда, не везде, не бесплатно по трудозатратам, но можно и это совершенно реально!
И бизнесу хорошо и нам есть что намазать на бутерброд.
Ну, у вас как был Linux, так и остаётся
У меня две домашние машины с Linux Gentoo. Два ядра из считающихся абсолютно стабильными веток. Между ними 3 месяца разницы и несколько минорных номеров. Одно ядро вообще беспроблемное — всё работает просто идеально. На второй машине обновил на более свежее и начались проблемы — через рандомное время крэшится всё что связано с иксами и сеансами пользователя. Подозреваю видеоподсистему, но надо сидеть разбираться. Пока просто откатил на то стабильное, трёхмесячной давности и всё опять в порядке.
К чему это я… Linux это такая же программа как всё остальное. И она может быть одним из сотен тысяч источников проблем для DevOps инженера. Не становитесь DevOps инженерами! И даже сисадминами не надо! :-)
…поддерживать работу сотен сервисов и сотен серверов…
Зачем это всё? Зачем только трудов и опасной ответственности? Слишком много рисков по сравнению с работой в сфере программирования! Не становитесь DevOps инженерами! :-D
Обнял. Всем желаю успехов от души! И DevOps, и простым пользователям.
Сделает! СДЕЛАЕТ! Окружение решает многое, если не всё! Сейчас обосную:
Предположим, Вы — бомж. У вас один уровень решаемых задач и проблем: где найти мусорник с едой и так, чтобы не побили «конкуренты»? Где переночевать при минус 15 (под мостом, как обычно не прокатит)? Как накатить чтобы забыться от всего этого и не думать о том, что будет завтра?
Теперь сравним с уровнем решаемых задач если Вы рядовой гражданин состоявшейся, социально-ориентированной страны без лишних потрясений: какая школа лучше ребёнку? Где комфортнее климат? Какое хобби лучше для души? Спорт? У какого работодателя интереснее задачи и выгоднее оплата? Какие интересные события можно организовать на завтра?
Есть такая мудрость, о которой сразу вспоминается в такие моменты: «Нельзя перейти море говна и не заляпаться, даже если ты в резиновых сапогах». Лучше сделать всё, чтобы держаться от такого «моря» подальше. Поэтому да, эмиграция — сделает жизнь лучше!
Сто́ит напомнить, что врать в завышать показатели — это часть культуры Китая. Из-за чего они вымирали миллионами во времена мао. Если верить их официальным заявлениям, так они и термояд уже давно победили, и в другие галактики летают на своих EmDrive. Поэтому понять что у них происходит с технологическими прорывами на самом деле очень и очень нелегко.
Хотя проблемы не столько с инновациями, а с их внедрением
Потому, что для внедрения любых инноваций нужны хорошо мотивированные и высококвалифицированные кадры, которые будут управляться стабильными бизнесами, владельцы которых уверены в своём "завтра", а так же в том, что их авторские права будут соблюдаться и защищатся международным правом. С учётом ТЕКУЩЕЙ обстановки, в пучину которой себя втянула страна, ничего из этого нет и не будет ещё десятилетиями.
Не исключено, что все мы ненамного переживем Вас после сингулярности. Вы немного теряете. Вероятность для всего человечества банально анекдотична: 50/50
Когда то давно появился многообещающий аналог — Бухгалтерская программа «Сибирский Ананас» https://sourceforge.net/projects/ananasproject/ Опенсорсное кроссплатформенное решение с теми же принципами как у "1С-Страдания", но лучше: - GUI на C++ и Qt - Встроенный скрпитовый язык разработки - Совместимость с опенсорсными базами данных
Еще тогда, много-много лет назад, я исследовал эту программу как альтернативу для перевода компании среднего масштаба. К сожалению, проявились нюансы, из-за которых почти сразу пришлось отказаться от этой идеи: - Программу разрабатывали пара седых ребят исключительно на энтузиазме. Этого оказалось мало для доведения программы до уровня конкуренции с оригинальным решением. - Qt фреймворк очень быстро эволюционировал и программа сильно отставала в миграции на новые мажорные версии. Это вызвало то, что на новых версиях Linux уже невозможно было найти библиотеки такой древности (и да, в компании на десктопах был Linux и бухгалтерия была единственным рудиментом, сидящим в терминале на винде ради той убогой 1C) - Встроенным языком был какой-то аналог JS внутри самого фреймворка Qt (сорри, подробностей не помню а уточнять — лень). Если ничего не путаю, то даже сами Qt потом отказались от поддержки этого языка в следующих версиях фреймворка по причине его крайней убогости и сложности освоения. - На тот момент развития программы невозможно было с помощью встроенного языка заменить весь фунционал 1С. Даже с учетом готовности компании переписать с нуля абсолютно всё, что было написано для 1С ранее, к сожалению, этого бы не получилось сделать в принципе!
Похоже, проект Ананас давно сколлапсировал, хотя исходники по-прежнему доступны и на удивление, официальная страничка до сих пор работает: http://ananas.su/
Искренне желаю процветания любым альтенативам типа "Ананас". Может быть кто-то решится и сделает аналогичное с нуля, или доведет до ума уже имеющееся! Ведь туда были заложены просто превосходные идеи, да и реализация была вполне годной. Хотя сейчас привязка к Qt кажется серьезной архитектурной ошибкой именно по причине отсутствия обратной совместимости новых версий со старым ПО на фоне эволюционирования на стероидах.
Еще была какая-то наколеночная альтернатива на Пютане (простите за мой французский), которая даже обещала 99% совместимость с оригинальным встроенным языком программирования гоВДноэски, но сейчас мне не удалось найти даже упоминаний, так она была популярна! :-D Может кто вспомнит?
Разгребая архивы новостей с начала апреля открыл и эту статью тоже. Она прекрасно смотрится на фоне подобных ей шедевров как: "Ватники нового поколения: нанотехнологии и расширение производства традиционных лаптей за счёт государственных инвестиций".
Прочёл просто чтобы поржать, вспоминая пословицу "Дурак мыслями богатеет". После прочтения прихожу к выводу, что лапти с нанотехнологиями смотрятся гораздо более реалистично чем процессоры.
Если бы он был, то такой х*@!и, как сейчас, не происходило бы!
Окружающий нас мир скорее результат стечения случайных событий на фоне теории больших чисел, чем управляемый волей механизм. И этому есть больше реальных доказательств, чем доказательств обратного. Во многих областях науки случайность и вероятностные процессы являются фундаментальными для понимания и описания окружающего мира: от квантовой физики, до биологии и математики (комбинаторика, теория хаоса)
Объяснения ключевых формулировок в статье непонятны. После третьей попытки осилить хотя бы четверть материала сделал для себя вывод, что статья вовсе не является попыткой выразить новую хоть чем то примечательную идею — это просто комок связного текста с умными словами и даже формулами. Модель всё ещё недообучена, поэтому пишет связно, но бестолково.
Сейчас да, я полностью соглашусь. Тогда, когда я только пробовал свою первую Raspberry Pi, задача стояла не в том ключе, чтобы разориться на покупку nvme, а попробовать вообще подойдёт малинка для тогдашних моих нужд или нет. Возможно да, это бы решило проблему UBOOT и расширило бы выбор OS, но сейчас меня итак устраивает и без лишних трат. Малинка прекрасно работает как backup-платформа, на которой можно даже что-то запустить с минимумом энергозатрат.
Ради результата. Сейчас у меня два ёмких диска на двух сторонах и я ничем не ограничен в своих желаниях хранить любой объём интересующих меня данных; синхронизация с проверкой и полная уверенность в идентичности данных; прямой доступ к данным через обе железки — к обеим точкам я могу за считанные секунды подключиться через интернет и добраться до любого файла.
Несомненно, HDD не конкуренты NVME дискам. И вообще магнитная технология заведомо обречена на увядание. Однако обещания Samsung выпустить четыре года назад NVME диски пользовательского уровня ёмкостью 100Tb пока так и остаются обещаниями. Учитывая ≅6 кратную разницу в стоимости хранения одного мегабайта продолжаем жить с HDD и жать светлого будущего.
NVME точно так же НЕ гарантируют 100% сохранности и доступности данных как и HDD. Рано или поздно, но и с любыми solid state возникнут проблемы. Даже солидных брендов. Технология увы, не совершенна. Это не просто слова, это неоднократный личный опыт.
Перед ответом я тщательно подумал над Вашим так точно заданным вопросом! И да, совершенно верно, была бы опция прерывания, — не было бы статьи, не было бы и моего личного опыта в борьбе с несовершенством цифровой реальности.
Но! На самом деле я рад этому опыту! Есть такой термин, часто используемый в разработке: Test Oracle — тестовый Оракул. Это некая независимая сущность, призываемая для проверки результата.
Ещё тогда, когда я уже начал использовать rsync для рабочих нужд, не до конца понимая всех нюансов его работы, я интуитивно чувствовал, что использовании единственного инструмента может таить угрозу. И потом, внезапно потеряв кусок важного дампа БД в DRC банка я в этом убедился воочию. Пришлось вникать в нюансы и строить процедуры периодического восстановления из бэкапов на архитектуре DRC. Это было чертовски сложно и долго, но действительно гарантировало восстановление работы на резервных ресурсах в случае проблем с основным DC. Это и был тот самый Оракул, который проверял результат.
precizer в данном случае тоже является оракулом, связанным с основным инструментом синхронизации, только через данные. Простым, но от этого не менее эффективным.
Угрозы могут идти не только от rsync. ПО или железо. Развалившийся RAID, проблемы с бэдблоками на дисках в более простых решениях, сбои на сетевом уровне, баги в ПО: как внутри rsync, так и в любом другом. Всё это несёт реальную угрозу рассинхронизации.
После наступания на «грабли» я теперь осознаю важность тестового Оракула. Не precizer, так какой-то другой инструмент. Поэтому все мои текущие и будущие решения в обязательном порядке будут построены на этом принципе.
От души благодарю. Значит не зря старался! Думаю, в будущем больше никто так не будет писать не потому, что весь мой айтишный опыт — продукт того самого диалапа, времён абсолютной свободы фидо, субкультуры udaff и padonkaf, а потому, что все ленятся и получается юридически выверенный, стерильный текст, выс…ый AI. Ну хорошо, может не ленятся, но экономят личный невозобновляемый ресурс — время.
Меня когда то сильно впечатлил стиль текстов Andy Weir: добрый, умный, сложный и с циничным юмором. Наверно, это теперь неосознанно отражается в том, к чему сам стремлюсь.
Сейчас вспоминаю и с удивлением осознаю, что раньше можно было писать обо всём и на любую тему, и за это тебе ничего не было (кроме злобных модераторов, которые могли кенсельнуть пост, конечно! :)
А теперь каждый телефон о тебе докладывает куда нужно и там где нужно знают о тебе больше, чем ты сам.
Хоть сейчас трава за моим окном и зеленее, чем была раньше за моим другим окном в прошлой жизни, но всё равно, поразительные и удивительные были времена! :-D
Моё первое знакомство с этим решением состоялось несколько лет назад, когда я пытался отправить родственнику через полпланеты огромный архив со словарями Goldendict и их индексацией. Тогда это казалось восхитительной идеей: и тебе торрент-протокол, и шифрование, и контрольные суммы и докачка. По-факту промучались неделю с нулевым результатом и пришлось искать альтернативные пути. Это при том что между нами нет ни каких DPI или какой-либо другой дряни, которая могла бы потенциально помешать передаче.
Потом была ещё одна попытка завернуть трафик syncthing в туннель или любой VPN и тоже безуспешно — эксперименты остановились на стадии исследования. Цель полностью недостижима архитектурно, несмотря на заверения нескольких источников в обратном.
Идеи заложены правильные, но тратить время на это кривое поделие я больше не хочу. Может быть, когда-нибудь, напишут на хорошем языке программирования что-то в таком же стиле, но действительно работающее. Но это будет уже не syncthing.
rsync не идеален, но он работает. Он полностью надёжен и предсказуем. Не вижу смысла менять что-то архитектурно, что уже проверено годами. Улучшить — да, можно. И статья именно об этом.
Мой опыт ограничивается только замерами на паре вариантов несильно старых x86_64 CPU, поэтому да, возможно мои выводы были поспешны. Спасибо за точку зрения!
Моё личное наблюдение — sha512sum работает быстрее, чем sha256sum
К предложенной схеме с find/rs/sort/diff есть несколько вопросов:
Если мне хочется проигнорировать директорию с сериалами, которые я вообще не бэкапирую и которые занимают половину диска? А если список для игнорирования состоит из трёх десятков пунктов? Лично в моём случае так и есть для rsync — передаю их параметрами в скрипте резервирования.
Что если мне нужно продолжить с прерванного места?
Что в плане обновлений через месяц, например, чтобы актуализировать все изменения после бэкапа? Перерасчёт с нуля всех 25Tb?
Вопросы не праздные — я в них упёрся в тот момент, когда сам продумывал решение и хотел нагородить проверку контрольных сумм на bash скриптах и системных утилитах. Думал, что ничего сложного нет.
Каким алгоритмом рассчитываются суммы? Это алгоритм с поддержкой многопоточности или под многопоточностью подразумевается обращение к диску в несколько потоков для чтения файлов? Просто интересуюсь.
Toshiba MG06ACA10TE 10Tb был заменён на Seagate ST28000NM000C-3WM103 25TB Добавлю, пожалуй, эти данные в статью, чтобы расставить все точки над «ё».
Хм… Ноут! Это Вы ещё не меняли картридж в струйных принтерах HP… Вот это действительно задача, за решение которой нужно выдавать Нобелевскую! :-D
Хотел бы как автор статьи написать ответ. Как мне показалось, Ваш комментарий был именно адресный. С одной стороны Вы во всём правы, ничего такого в DevOps неправильного нет. Всё разумно, логично, взаимосвязано и абсолютно последовательно соблюдаются все причинно следственные связи. Но…
Если бы только ограничивалось постгрёй и мускелем. Ан нет… Это вообще не из сферы DevOps. Там этого не достаточно. Им подавай Aurora, DynamoDB, DocumentDB, Keyspaces, Neptune, Timestream LiveAnalytics, Redshift, RDS (отдельный зоопарк), ElastiCache, MemoryDB, OpenSearch Service и это только стэк Amazon Web Services и только в сфере БД. Перечислить зоопарк остальных вендоров? Не? Хватит?
Не лень. Просто реально ни времени ни оперативы держать в голове весь этот бардак не хватает просто биологически. Слишком много информации и слишком ко́роток срок жизни этих технологий. Думаю через 10 лет даже половины из перечисленного списка либо не будет уже существовать вообще, либо они трансформируются во что-то совершенно другое.
Тут много раз в комментариях уже упоминался именно этот термин. И да, нельзя не согласиться с целесообразностью его использования. Статья действительно получилась уж сильно эмоциональной, очень “соль на рану” и по-живому. Потому что тогда рана действительно была и она здорово припекала. Новые поиски работы, новые сомнения, моральные страдания и то чувство, когда ощущаешь себя ничтожеством среди мэтров своего дела на очередном собесе, на котором тебя носом тычут в новые технологии и недоумевают как такие “элементарные” вещи можно не знать.
Не знаю их и больше знать не хочу! Вот честно!
Сколько прошло с тех времён? Год? Полтора? Только что прокрутил до даты создания статьи. Нда… Потрясно… Два года уже прошло! За два года эмоции поутихли, но лично моё мнение сформировалось надёжно и наверно уже навсегда. Сейчас можно честно признавать, что в статье больше эмоций чем объективной оценки средней температуры по палате. За что статью не раз критиковали (обосновано) в комментариях. Которые сами нередко были предельно эмоциональны… Ну да ладно… Мы все люди а не роботы, у нас есть чувства, эмоции и не только умом и холодным расчётом формируется наша жизнь и профессиональные предпочтения.
Пару лет назад я сделал выбор и надо сказать что очень удачный. Сейчас меня устраивает буквально всё. AI убрал из программирования ту тупую рутину печатания, которая многих вводила в уныние. Лично я просто в восторге от процесса кодинга с агентами! Чувствую себя художником, а не “машинисткой” печатной машинки, вынужденной к тому же угадывать синтаксис разыменования указателей. В моей жизни теперь много Си и на работе и как хобби и я ну ни капли не жалею о таком радикальном развороте моей профессиональной карьеры, к которому я упорно шёл сквозь годы. Я расту и совершенствуюсь в этом ЯП. Да, он сложный и даже после долгих лет работы открываешь для себя много нового снова и снова. Особенно, когда есть AI у которого можно получить разъяснения, а не так как раньше: ждёшь ответа неделями, но так и не получаешь. Потому что профи либо заняты, либо лень, а остальные 99,99999% прочитавших вопрос просто не знают на него ответа.
Чего в моей жизни больше нет или что улучшилось за это время:
Теперь я сплю крепко даже тогда, когда условно “дежурный” на телефоне (как разработчик). Я далеко не первая линия обороны между конечными потребителями и продуктом который пишу и за всё это время ни разу меня не побеспокоили именно по поводу проблем с ним связанным.
Нет тех тревог, которые были из-за уровня ответственности за продакшн и проблем связанных с многослойностью технологий, когда на каждом этапе что-то может пойти не так и всё — конец покою и кроме тебя, девопса и виноватых-то больше найти не получится!
Я отвечаю только за ОДНУ(!) софтину которую пишу, а не за тот зоопарк технологий наговнокоженный абы-как и кем попало под громкими брендами типа Amazon или Oracle. Если отвалилась из сети пачка серверов с моей софтиной, то кто виноват? Правильно — кто угодно, но не я. Моя софтина как выключатель: либо работает, либо нет — тут всё просто. А кто отвечает за всё остальное? Маршрутизация, внутренняя сеть, железо, виртуализация, кластеризация, контейнеризация, операционки, обновления, ядра, драйверы? Правильно: команда тех самых девопс-инженеров, мечтающая выспаться хоть разочек. Мне остаётся только утром вместо новостей с чашкой кофе читать сводки по сбоям (так… по-диагонали пробежаться, чтобы понять затрагивает это мой сектор или нет).
Вот всё на первый взгляд в DevOps логично и правильно:
Виртуализация — это совершенно логичный шаг в попытке рационально уплотнить использование софта на очень быстро эволюционирующем железе.
Контейнеризация — такой же логичный шаг в направлении развития деплоймента, миграции, отказоустойчивости, изоляции и версионирования.
IaC — абсолютно разумная технология в попытке навести порядок и управлять сотнями и тысячами единиц ресурсов.
Но всё это логично и правильно только на первый взгляд. По факту, все эти красивости состоят из стянутых кое-как и склеенных соплями в пучок сотен тысяч программно-аппаратных компонентов разных производителей и у разных поставщиков услуг (библиотеки, комплексные программы, чипы, прошивки, операционки, ядра, драйверы устройств) в которых есть миллионы своих мелких или крупные багов и скрытых проблем. И DevOps не только не контролирует ни одну из этих миллионов скрытых проблем, он даже не подозревает об их существовании, потому что инженер управляет сущностями на совершенно другом уровне абстракции.
Приведу простой пример: терраформ работал-работал и вдруг перестали выставлять проперти на s3 бакет. Один долбаный бакет! Накатываем - откатывается. Каждый этап — полчаса. Бьёмся день. Где баг? В конфиге этого бакета, который не менялся уже как год? Через что-то другое задели, потому что настройки пропертей шарятся среди десятков других сториджей? В день делается с десяток изменений командой из нескольких человек. Кто поломал? Откат гитом всей конфигурации на сутки назад: тот же результат — не можем накатить вообще никаких изменений из-за этого одного бакета. Выставляем проперти вручную — всё работает. Неделя в попытках разобраться спускается в унитаз и под занавес — проблема исчезает сама собой. В анонсах AWS - ни слова ни о баге ни о его ремонте. Неделя отравленного времени, настроения, скандалов и бессонницы, обвинения от кого угодно в некомпетентности и даже саботаже на всех уровнях руководства. Всё это — банальный график ежедневной работы рядового DevOps инженера. Надо оно лично мне? О нет! Уверен — не хочу во всё это окунаться больше ни разу, даже если мне при этом будут подавать ключи (как в том анекдоте).
Одна из тех причин почему выбор пал именно на Си, это самодостаточность. Программе на Си не нужны виртуальные движки как Java, PHP или NodeJS с их версионностью, багами, деприкейтами и legacy, не нужны кеширующие прекомпиляторы и другие костыли. Не нужны зависимости, зависящие от зависимых зависимостей в которых постоянно находят чужие интружены (сорян, каламбур сам по себе напрашивался, навеянный dependencies в NodeJS и проблемами с ними связанными).
В Си тоже широко используются библиотеки, но это не разрушает самодостаточности. Чем выше самодостаточность — тем меньше потенциальных точек отказа, тем выше стабильность, предсказуемость и контролируемость. То, чего мне не хватало в DevOps — ощущения стабильности, предсказуемости и контроля, я в гораздо большей степени нашёл в Си-разработке.
На работе у меня код, который писался в течение 35 лет и насчитывает около 170 000 строк. Сложный, стабильный и с нулевым покрытием юнит-тестами (тогда TDD был не в фаворе) К тому же, код изначально писался и развивался под AIX (была такая OS, а может и есть до сих пор) которая, кстати, big-endian с нативной кодировкой EBCDIC вместо привычной нам ASCII. И что? И ничего! За пару месяцев весь этот код без особых последствий силами двух очень хорошо разбирающихся программистов портировали на Linux x86_64 который уже little-endian. Теперь софт продолжает успешно трудиться на фундаментально другом железе, другой операционке и собранный абсолютно другим компилятором.
В чём тут принципиальное отличие от философии DevOps? Нет лишних слоёв абстракций! Всё максимально просто, поэтому надёжно как до сих пор работающий лом, доставшийся в наследство от прадедушки вместе с сарайчиком, в котором стоят пластиковые китайские грабли, гнущиеся в нужных и, главное, в ненужных местах на все 180 градусов, как современные облачные технологии, прогибающиеся под прихоти в самые замысловатые позы.
DevOps как набор идей логичен. Но конкретная работа DevOps-инженера во многих компаниях превращается в жизнь на стыке чужих абстракций, чужих багов, чужих API, чужих бизнес-решений и твоей персональной ответственности. Лично мне этот тип нагрузки оказался разрушителен.
Пишет! :-D
Даже фреймворки есть, чтобы не приходилось мудрить на примитивном уровне с printf(“%s”,"<html "); и даже их несколько. Прекрасно себе живут и пользуются популярностью, потому что софт на их базе потребляет в 10-20 раз меньше ресурсов по сравнению аналогичными решениями на других ЯП. Там где под Java web-приложение нужно 20 серверов под такую же логику программе на Си потребуется только два. Не всегда, не везде, не бесплатно по трудозатратам, но можно и это совершенно реально!
И бизнесу хорошо и нам есть что намазать на бутерброд.
У меня две домашние машины с Linux Gentoo. Два ядра из считающихся абсолютно стабильными веток. Между ними 3 месяца разницы и несколько минорных номеров. Одно ядро вообще беспроблемное — всё работает просто идеально. На второй машине обновил на более свежее и начались проблемы — через рандомное время крэшится всё что связано с иксами и сеансами пользователя. Подозреваю видеоподсистему, но надо сидеть разбираться. Пока просто откатил на то стабильное, трёхмесячной давности и всё опять в порядке.
К чему это я… Linux это такая же программа как всё остальное. И она может быть одним из сотен тысяч источников проблем для DevOps инженера. Не становитесь DevOps инженерами! И даже сисадминами не надо! :-)
Зачем это всё? Зачем только трудов и опасной ответственности? Слишком много рисков по сравнению с работой в сфере программирования! Не становитесь DevOps инженерами! :-D
Обнял. Всем желаю успехов от души! И DevOps, и простым пользователям.
Сделает! СДЕЛАЕТ! Окружение решает многое, если не всё! Сейчас обосную:
Предположим, Вы — бомж. У вас один уровень решаемых задач и проблем: где найти мусорник с едой и так, чтобы не побили «конкуренты»? Где переночевать при минус 15 (под мостом, как обычно не прокатит)? Как накатить чтобы забыться от всего этого и не думать о том, что будет завтра?
Теперь сравним с уровнем решаемых задач если Вы рядовой гражданин состоявшейся, социально-ориентированной страны без лишних потрясений: какая школа лучше ребёнку? Где комфортнее климат? Какое хобби лучше для души? Спорт? У какого работодателя интереснее задачи и выгоднее оплата? Какие интересные события можно организовать на завтра?
Есть такая мудрость, о которой сразу вспоминается в такие моменты: «Нельзя перейти море говна и не заляпаться, даже если ты в резиновых сапогах». Лучше сделать всё, чтобы держаться от такого «моря» подальше. Поэтому да, эмиграция — сделает жизнь лучше!
Можно вступить в секту "с" (без единицы) :-D https://habr.com/ru/articles/811429/
Сто́ит напомнить, что врать в завышать показатели — это часть культуры Китая. Из-за чего они вымирали миллионами во времена мао. Если верить их официальным заявлениям, так они и термояд уже давно победили, и в другие галактики летают на своих EmDrive. Поэтому понять что у них происходит с технологическими прорывами на самом деле очень и очень нелегко.
Потому, что для внедрения любых инноваций нужны хорошо мотивированные и высококвалифицированные кадры, которые будут управляться стабильными бизнесами, владельцы которых уверены в своём "завтра", а так же в том, что их авторские права будут соблюдаться и защищатся международным правом. С учётом ТЕКУЩЕЙ обстановки, в пучину которой себя втянула страна, ничего из этого нет и не будет ещё десятилетиями.
Не исключено, что все мы ненамного переживем Вас после сингулярности. Вы немного теряете. Вероятность для всего человечества банально анекдотична: 50/50
Вся машина едет по дороге в пропасть. А без приказа и свернуть ссыкотно. Поэтом все дружно под откос! В этом проблема, ни в чём другом.
Нет 1с — нет проблемы. С кошкой то же самое ;-D
Когда то давно появился многообещающий аналог — Бухгалтерская программа «Сибирский Ананас» https://sourceforge.net/projects/ananasproject/
Опенсорсное кроссплатформенное решение с теми же принципами как у "1С-Страдания", но лучше:
- GUI на C++ и Qt
- Встроенный скрпитовый язык разработки
- Совместимость с опенсорсными базами данных
Еще тогда, много-много лет назад, я исследовал эту программу как альтернативу для перевода компании среднего масштаба. К сожалению, проявились нюансы, из-за которых почти сразу пришлось отказаться от этой идеи:
- Программу разрабатывали пара седых ребят исключительно на энтузиазме. Этого оказалось мало для доведения программы до уровня конкуренции с оригинальным решением.
- Qt фреймворк очень быстро эволюционировал и программа сильно отставала в миграции на новые мажорные версии. Это вызвало то, что на новых версиях Linux уже невозможно было найти библиотеки такой древности (и да, в компании на десктопах был Linux и бухгалтерия была единственным рудиментом, сидящим в терминале на винде ради той убогой 1C)
- Встроенным языком был какой-то аналог JS внутри самого фреймворка Qt (сорри, подробностей не помню а уточнять — лень). Если ничего не путаю, то даже сами Qt потом отказались от поддержки этого языка в следующих версиях фреймворка по причине его крайней убогости и сложности освоения.
- На тот момент развития программы невозможно было с помощью встроенного языка заменить весь фунционал 1С. Даже с учетом готовности компании переписать с нуля абсолютно всё, что было написано для 1С ранее, к сожалению, этого бы не получилось сделать в принципе!
Похоже, проект Ананас давно сколлапсировал, хотя исходники по-прежнему доступны и на удивление, официальная страничка до сих пор работает: http://ananas.su/
Искренне желаю процветания любым альтенативам типа "Ананас". Может быть кто-то решится и сделает аналогичное с нуля, или доведет до ума уже имеющееся! Ведь туда были заложены просто превосходные идеи, да и реализация была вполне годной. Хотя сейчас привязка к Qt кажется серьезной архитектурной ошибкой именно по причине отсутствия обратной совместимости новых версий со старым ПО на фоне эволюционирования на стероидах.
Еще была какая-то наколеночная альтернатива на Пютане (простите за мой французский), которая даже обещала 99% совместимость с оригинальным встроенным языком программирования го
ВДноэски, но сейчас мне не удалось найти даже упоминаний, так она была популярна! :-D Может кто вспомнит?Разгребая архивы новостей с начала апреля открыл и эту статью тоже. Она прекрасно смотрится на фоне подобных ей шедевров как: "Ватники нового поколения: нанотехнологии и расширение производства традиционных лаптей за счёт государственных инвестиций".
Прочёл просто чтобы поржать, вспоминая пословицу "Дурак мыслями богатеет". После прочтения прихожу к выводу, что лапти с нанотехнологиями смотрятся гораздо более реалистично чем процессоры.
Всех с первым апреля! :-D
Кроме этих, встроенных, штоле? https://habr.com/ru/companies/globalsign/articles/893562/
Вольфрам предлагает интерпретировать физику окружающего нас мира через графы. Пересечение с концепцией автора примечательно хотя бы в том, что рекурсия и графы шагают нога-в-ногу.
Окружающий нас мир скорее результат стечения случайных событий на фоне теории больших чисел, чем управляемый волей механизм. И этому есть больше реальных доказательств, чем доказательств обратного. Во многих областях науки случайность и вероятностные процессы являются фундаментальными для понимания и описания окружающего мира: от квантовой физики, до биологии и математики (комбинаторика, теория хаоса)
Объяснения ключевых формулировок в статье непонятны. После третьей попытки осилить хотя бы четверть материала сделал для себя вывод, что статья вовсе не является попыткой выразить новую хоть чем то примечательную идею — это просто комок связного текста с умными словами и даже формулами. Модель всё ещё недообучена, поэтому пишет связно, но бестолково.
Косвенно это подтверждает, что Дуров СОТРУДНИЧАЕТ с фсб и чтобы отвести все подозрения объявлена госзакупка.