Search
Write a publication
Pull to refresh
1
0
Send message
Вы обновили библиотеку HTTP запросов до самой последней версии в последнем релизе.
Нда? А к «элегантной программе», «с точно требуемым количеством абстракций», «безупречны модулям» — тестирования не прилагалось?

И «самый почтенный по годам специалист компании» не станет произносить эту мудрую, но бессмысленную в данной ситуации фразу выделенную курсивом (ради которой, очевидно, и писался рассказ). А бросит коротко — «ну, что ж откатывайся, а потом действуй по своему плану». Еще может быть, для одобрения, пошутит вроде: «в этим мире нельзя никому доверять,… мне можно».
Вы в общем то правы, это нормальное поведение для обычного «рабочего» (слесаря к примеру). Только вот проблема в том, что программисты в IT это не слесаря, это инженеры. В ваших терминах скорее всего подойдет аббревиатура ИТР (как в общем любом производстве). Я сомневаюсь что хорошие ИТР на производстве слепо следуют указаниям начальства.
В свое время я работал в металлургии и помню как инженеры и директора матом друг друга крыли на планерках обсуждая какую то проблему, при этом ни кто тупым приказам сверху почему то слепо не следовал. После конечно, приходили к какому то консенсусу, и производство не вставало, или возвращалось в нормальный режим работы. От части только потому, что есть ИТР работники которые думают головой.
Если начальник сойдет с ума и прикажет вместо перфоратора пробивать стену головой, то до приезда санитаров следует безоговорочно биться головой о стену — это будет единственный ПРАВИЛЬНЫЙ поступок любого работника.

Вы описали обычное армейское слепое повиновение.

Правильный поступок — это ПОЛОЖИТЬ БОЛТ на неадекватный приказ.
Процитирую военного гения Сунь-Цзы, написавшего «Искусство войны»:
Бывают дороги, по которым не идут; бывают армии, на которые не нападают; бывают крепости, из-за которых не борются; бывают местности, из-за которых не сражаются; бывают повеления государя, которых не выполняют.
>> начальство прикажет вам разбить, это следует немедля сделать
>Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты.
Согласен с предыдущим ораторам. Я при возникновении проблем прихожу к начальнику с несколькими решениями, объясняю о плюсах и минусах, и просто, предлагаю ему выбор
И еще добавлю. Менеджер – не начальник над разработчиком. Это роли одного уровня.
Не совсем так. Например, если Вы выполняете приказ более вышестоящего начальника (в нашем случае требований качества ПО), то Вы обязаны доложить об этом отдавающему приказ, и после этого он принимает решение — повторить приказ и тогда Вы обязаны его выполнять или не повторять.

А когда речь идет о производстве, то служебная (докладная) записка с перечнем возможных проблем и Ваша совесть чиста и через месяц на вопрос начальника «А Вы не предупреждали, что так нельзя» чпокойно демонстрируете копию с его подписью.
В армии, в уставе есть пункты:
1. про то что надо выполнять приказ, а потом оспаривать
2. если приказ унижает личное достоинство подчинённого, его можно НЕ ВЫПОЛНЯТЬ.
Так что там тоже не всё так плохо и головой биться об стены не обязательно.
Это касается всего инженерного состава. Они же все либо придумывают детальки, либо собирают из деталей убермашины. Да и программисты, если так подумать, тоже инженеры. Куча непонятных терминов, постоянно витают в облаках, результат труда не ясен до завершения, требуются навыки а гуманитарных областях, и вишенка на торте — 100500 ошибок на выходе.
Вы описали обычное армейское слепое повиновение.
> Биться головой об стену
Кажется, голова не хозяйская, а своя. Если только тебя не продали в рабство

> начальство прикажет вам разбить, это следует немедля сделать
Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты. И если он скажет убрать не нужный сервер, и вы удалите по слепому приказу сервак менеджеров(продавцов. Ведь сервак вам не нужен?), то выкручиваться в стиле «мне приказали, я сделал» не получится. Начальник покрутит у виска, спросит зачем тебе голова и попросит увольняться, и будет прав в целом.

На заводах люди совсем по-другому работают, чем в бизнесе. Одно ваше слово «ХОЗЯЙСКОЕ» о многом говорит. И к воровству там относятся проще, мол хозяин жадничает, вот я и утащил. Возможно, приказы на заводе и дело вынужденное, но не могу говорить за другие места.
И манагер и девелопер — зелень. Манагер был бы крутым, если бы не орал, а девелоперу надо понимать как можно «похачить» чтобы и система не «взорвалась» и пользователь остался доволен. Цель работающее ПО, какие хаки внутри — проблема компании. Конечному пользователю абсолютно до лампочки.
очень интересно, но не оставляет впечатление «каши из топора».
В том смысле, что берем кэш, прикручиваем к нему фичи БД, выкидываем девяносто процентов данных в другую «медленную» базу, и он показывает чудеса производительности в качестве БД. И не понятно, толи выигрыш за счёт замечательной архитектуры, толи за счёт выигрыша по объему. Правда используют хранение данных в памяти, а не на диске, что может дать выигрыш в скорости.
И как отметили, интересно было бы почитать, как происходит разбивка данных на горячие и холодные.
Спасибо, прочитал. Понял, что все ~100GB хранятся в RAM. Если честно, то очень сомневаюсь в таком подходе. Ну — во всяком случае не понимаю зачем для этого отдельная БД. У всех современных БД есть подсистема кэширования. Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией. + не понятно что значит что транзакции выполняются в одном потоке… Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае? А если это распределенные транзакции?
Посмотрите например вот это или можете сами поискать доклады Константина Осипова он архитектор этой БД и уже есть достаточно много записей его докладов, где он достаточно подробно и на понятном языке рассказывает как устроен tarantool, для каких задач оптимизирован и какие есть плюсы и минусы у этой БД.
Могу пригласить мейлрушных админов в чат. С точки зрения эксплуатации — одна из самых простых СУБД в мире. Бэкапить можно прямо на горячюю, копированием файлов из под базы. Либо через встроенный инструмент создания реплики (по сути — создается реплика и тут же отключается от мастера — вот и бэкап). В обоих случаях бэкап всегда целостный и производительность СУБД во время создания бэкапа не приседает. Целостность гарантируется. Можно включить в настройках fsync, можно выключить — тут ничем от других классических СУБД не отличается. Сломаться — я такого не припомню. Извлечь можно все из логов и из снэпшотов. Более того, если из-за бага в коде в базу пришел плохой коммит, то его можно выкусить из середины. Делается это так — берется старый снэпшот (до коммита) и на него накатываются все логи, с исключением из них плохого коммита. Деградация возможна, если запустить долгоиграющие хранимые процедуры (с пустыми циклами, например). Не делайте так :-)

Его 3 раза об этом спрашивали, но он так толком и не ответил… Видимо, в их кейсе не учитывается остывание данных.

Не понятно кто и как управляет распределением холодных и горячих данных, это какой-то внешний процесс или тарантул сам скидывает редко используемые данные в «холодное хранилище»?
Не совсем понимаю. Если вы сделали кэш а-ля свою кэширующую БД на 100GB, то какое основное отличие от обычной БД, благодаря которому обращение к данным происходит быстрее? Принцип хранения данных? По итоговой схеме становится понятно, что к MySQL обращения происходят более редко за счет того, что ко всем горячим данным они идут в tarantool. Но ведь т.о. большая часть нагрузки теперь падает на него. Цитирую: «Мы разработали специальную базу данных для горячих данных» — из этого понятно только то, что большая часть обращений будет падать на вашу новую бд, которую также придется маштабировать. Можете как-то уточнить?

Хорошо бы вспомнить еще один очень важный параметр — надежность в широком смысле этого слова.


Классические СУБД отличаются еще и тем, что им можно доверить важные данные, а что касается NoSQL и прочих хранилищ новой формации...


  • поддерживают ли они атомарные бэкапы?
  • можно ли гарантировать сохранность данных после подтвержденного коммита? В том числе при отказе железа?
  • При каких условиях база может сломаться? как извлечь данные из разломанной базы?
  • возможна ли деградация производительности по каким-либо причинам? Что делать, если наша база внезапно начала работать медленно?

И прочие неприятные моменты, которые выясняются только при эксплуатации.

Да и он даже больше для этого подходит. Но цель статьи показать на живом примере, что php можно так же использовать для пользовательских скриптов.

Мне вспоминается притча Мастер Фу и десять тысяч строк кода.
На bash это можно сделать вот так:


AUTH='USER:PASSWORD'
FILE=$(date +'%Y_%m_%d_%H_%M_%S_screen.png')
XML='<propertyupdate xmlns="DAV:"><set><prop><public_url xmlns="urn:yandex:disk:meta">true</public_url></prop></set></propertyupdate>'

scrot -s "/tmp/$FILE"
curl -s --user "$AUTH" -T "/tmp/$FILE" -X PUT "https://webdav.yandex.ru/"
curl -s --user "$AUTH" -d "$XML" -X PROPPATCH "https://webdav.yandex.ru/$FILE" | grep -Eo 'https://yadi.sk/[^<]+'
rm -f "/tmp/$FILE"

Information

Rating
Does not participate
Registered
Activity