Steeply

Steeply

Пикабушник
Дата рождения: 01 апреля 1987
поставил 1 плюс и 1 минус
отредактировал 0 постов
проголосовал за 0 редактирований
Награды:
5 лет на Пикабу
30К рейтинг 10 подписчиков 15 подписок 18 постов 2 в горячем

Сбермаркет в своем репертуаре

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

Дожидаюсь доставки, встречаю курьера. Забираю продукты. Открываю и чувствую, что меня уже налюбили.

Я думаю все из вас представляют как выглядят стейки?

Если нет, то вот так:

Сбермаркет в своем репертуаре Сбермаркет, Защита прав потребителей, Обман клиентов, Длиннопост, Негатив

Стейк форели.

Вместо заказанных мною стейков форели, провезли обрезки хвостов. Да еще сколько, целых 2 мешка, вместо нескольких крупных стейков.

Поскольку чую срыв мероприятия и позор перед гостями, сразу же бегу в тот же ОКЕЙ и покупаю нормальные стейки.

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

Оператор спрашивает всю необходимую информацию, что не так с товаром, когда заказывали и т.д.

Сбермаркет в своем репертуаре Сбермаркет, Защита прав потребителей, Обман клиентов, Длиннопост, Негатив

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

Сбермаркет в своем репертуаре Сбермаркет, Защита прав потребителей, Обман клиентов, Длиннопост, Негатив

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

Сбермаркет в своем репертуаре Сбермаркет, Защита прав потребителей, Обман клиентов, Длиннопост, Негатив

Чат поддержки Сбермаркета

На следующий день курьер не пришел. И через день тоже.

Но вместо курьера меня ожидал звонок из кол-центра Сбермаркета. Девушка очень извинялась за сложившуюся ситуацию, поинтересовалась еще раз подробностями и что меня не устроило в товаре и какие у меня претензии к магазину. Я снова озвучил свои претензии и пожелания, сказал, что к магазину у меня нет вопросов, у меня вопросы к сборщику (ведь именно он для этого и нужен, чтобы контролировать и собирать заказ, а иначе в чем вообще смысл сего сервиса?). Девушка посмотрела еще раз фотографии того, что они прислали. Посмеялась над такими "щедрыми" стейками, посочувствовала и сказала что во всем разберутся.

На следующий день снова позвонили из кол-центра. Снова начали с тысячи извинений, как все некрасиво получилось, и как они мне сочувствуют. Девушка так же огласила, что магазин отказался обменивать товар, так как по его мнению с товаром все отлично и никаких дефектов в нем нет (а то что привезли не стейки, а хвосты, но это же рыба). Но со свой стороны Сбермаркет понимает и уважительно относится к своим клиентам (да и виноватым вроде бы был сборщик, что такое допустил), по этому они приняли решения, что вернут мне потраченные средства, а товар я могу оставить у себя. Я перепросил несколько раз, точно ли товар не нужно возвращать потому что я все еще жду курьера чтобы отдать это недоразумение? Ответ был утвердительным. На этом и попрощались.

Через 3 дня сбермаркет вернул деньги на счет.

Сбермаркет в своем репертуаре Сбермаркет, Защита прав потребителей, Обман клиентов, Длиннопост, Негатив

Возврат средств.

Но как вы понимаете, на этом все бы и закончилось и этого поста не было, если бы Сбермраркет не был самим собой.

Через 8 дней, мне звонят снова из кол-центра и уже настойчево просят вернуть деньги. Так как они подумали и решили, что их коллеги вынесли неправильное решение по возврату. Для возврата им средств мне предложили создать фиктивный заказ на эту же сумму и оплатить его. (Каким обзором я должен создать заказ копейка в копейку, при этом не получать заказ оператор явно не подумал.)

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

Спустя 2 дней, Сбермаркет сам списывает эту же сумму обратно.

Сбермаркет в своем репертуаре Сбермаркет, Защита прав потребителей, Обман клиентов, Длиннопост, Негатив

Я снова написал в чат с вопросом. Но к сожалению там мне никакого ответа не дали. Составили обращения и пообещали разобраться. (Номер обращения №21634787)

Сбермаркет в своем репертуаре Сбермаркет, Защита прав потребителей, Обман клиентов, Длиннопост, Негатив

Ну и как это называется Сбермаркет? Т.е вы сами накосячили с заказом, отказались его забирать. Приняли решения вернуть деньги, при этом списали с меня сберСпасибо. А теперь самолично просто списываете с меня деньги обратно, при этом вы даже не можете обосновать на каком основании и согласно какому закону вы это делаете? Закон о защите прав потребителя для вас роли не играет?

Показать полностью 7

Прошу помощи найти отвертку.

macbook pro retina 2012 (a1398)

Какая отвертка нужна чтобы открутить указаный винт?

Очень похоже на T5 Torx но она не подходит (болтается), а T6 Torx большая.

Прошу помощи найти отвертку. Помощь, Отвертка, Macbook

Робот уборщик.

Приехал сегодня домой в родной город. Щелкал каналы, и натыкаюсь на канал новостей местной администрации. Посмотрел, остался вопрос, что за?

Когда не о чем писать новости на НТВ

Когда не о чем писать новости на НТВ НТВ, Бред, Призрак, Стекло, Отражение

На селфи Хейли из Джорджии четко видно, что позади автомобиля, в котором находится девочка, стоит мужчина в бейсболке с оскалом.


Фотографию с жутким изображением разместила на странице в Facebook мать девочки Джессика Оглетри. «Я клянусь, что сзади нас никого не было. Более того, даже на обочине на всем пути на рыбалку не стояло ни единого человека», — написала женщина.


Впрочем, отмечает американка, призрак явно находится в хорошем расположении духа, поэтому, возможно, его появление — это хороший знак, передает «Вести.Ru».


http://www.ntv.ru/novosti/1778672/

Показать полностью 1

Инцидент с базой данных GitLab.com от 31/01/2017

Инцидент с базой данных GitLab.com от 31/01/2017 Gitlab, Резервное копирование, Перевод, События, Происшествие, IT, Длиннопост

31 января 2017 года произошло важное для мира OpenSource событие: один из админов GitLab.com, пытаясь починить репликацию, перепутал консоли и удалил основную базу PostgreSQL, в результате чего было потеряно большое количество пользовательских данных, и сам сервис ушел в офф-лайн. При этом все 5 различных способов бэкапа/репликации оказались нерабочими. Восстановились же с LVM-снимка, случайно сделанного за 6 часов до удаления базы.


Понесенные потери


Потеряны данные за примерно 6 часов.

Потеряно 4613 обычных проектов, 74 форка и 350 импортов (грубо); всего 5037. Поскольку Git-репозитории НЕ потеряны, мы сможем воссоздать те проекты, пользователи/группы которых существовали до потери данных, но мы не сможем восстановить задачи (issues) этих проектов.

Потеряно около 4979 (можно сказать, около 5000) комментариев.

Потенциально потеряно 707 пользователей (сложно сказать точнее по логам Kibana).

Веб-хуки, созданные до 31 января 17:20, восстановлены, созданные после — потеряны.



Хронология (время указано в UTC)


2017/01/31 16:00/17:00 — 21:00

- YP работает над настройкой pgpool и репликацией в staging, создает LVM-снимок, чтобы загрузить боевые данные в staging, а также в надежде на то, что сможет использовать эти данные для ускорения загрузки базы на другие реплики. Это происходит примерно за 6 часов до потери данных.

- Настройка репликации оказывается проблематичной и очень долгой (оценочно ~20 часов только на начальную синхронизацию pg_basebackup). LVM-снимок YP использовать не смог. Работа на этом этапе была прервана (так как YP была нужна помощь другого коллеги, который в тот день не работал), а также из-за спама/высокой нагрузки на GitLab.com.


2017/01/31 21:00 — Всплеск нагрузки на сайт из-за спамеров

- Блокирование пользователей по их IP-адресам

- Удаление пользователя за использование репозитория в качестве CDN, в результате чего 47 000 айпишников залогинились под тем же аккаунтом (вызвав высокую нагрузку на БД). Информация была передана командам технической поддержки и инфраструктуры.

- Удаление пользователей за спам (с помощью создания сниппетов)

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


2017/01/31 22:00 — Получено предупреждение об отставании репликации

- Попытки починить db2, отставание на этом этапе 4 GB.

- db2.cluster отказывается реплицироваться, каталог /var/opt/gitlab/postgresql/data вычищен, чтобы обеспечить чистую репликацию.

- db2.cluster отказывается подключаться к db1, ругаясь на слишком низкое значение max_wal_senders. Эта настройка используется для ограничения количества клиентов WAL (репликации).

- YP увеличивает max_wal_senders до 32 на db1, перезапускает PostgreSQL.

- PostgreSQL ругается на то, что открыто слишком много семафоров, и не стартует

- YP уменьшает max_connections с 8000 до 2000, PostgreSQL стартует (при том, что он нормально работал с 8000 почти целый год).

- db2.cluster все еще отказывается реплицироваться, но на соединения больше не жалуется, а вместо это просто висит и ничего не делает.

- В этот время YP начинает чувствовать безысходность. Раньше в этот день он сообщил, что собирается заканчивать работу, так как становилось уже поздно (около 23:00 по местному времени), но он остался на месте по причине неожиданно возникших проблем с репликацией.


2017/01/31 около 23:00

- YP думает, что, возможно, pg_basebackup чересчур педантичен по поводу чистоты директории для данных и решает ее удалить. Спустя пару секунд он замечает, что запустил команду на db1.cluster.gitlab.com вместо db2.cluster.gitlab.com.

- 2017/01/31 23:27: YP отменяет удаление, но уже слишком поздно. Из примерно 310 Гб осталось только 4.5



Восстановление — 2017/01/31 23:00 (бэкап от ~17:20 UTC)


Предложенные способы восстановления:

1. Смигрировать db1.staging.gitlab.com на GitLab.com (отставание около 6 часов)

- CW: Проблема с веб-хуками, которые были удалены во время синхронизации.

2. Восстановить LVM-снимок (отстает на 6 часов).

3. Sid: попробовать восстановить файлы?

- CW: Невозможно! rm -Rvf Sid: OK.

- JEJ: Наверное, уже слишком поздно, но может ли помочь, если достаточно быстро перевести диск в режим read-only? Также нельзя ли получить дескриптор файла, если он используется работающим процессом (согласно http://unix.stackexchange.com/a/101247/213510).

- YP: PostgreSQL не держит все свои файлы постоянно открытыми, так что это не сработает. Также, похоже, что Azure очень быстро удаляет данные, а вот пересылает их на другие реплики уже не так шустро. Другими словами, данные с самого диска восстановить не получится.

- SH: Похоже, что на db1 staging-сервере отдельный PostgreSQL-процесс льет поток production-данных с db2 в каталог gitlab_replicator. Согласно отставанию репликации, db2 был погашен в 2016-01-31 05:53, что привело к остановке gitlab_replicator. Хорошие новости заключаются в том, что данные вплоть до этого момента выглядят нетронутыми, поэтому мы, возможно, сможем восстановить веб-хуки.


Предпринятые действия:

2017/02/01 23:00 — 00:00: Принято решение восстанавливать данные с db1.staging.gitlab.com на db1.cluster.gitlab.com (production). Несмотря на то, что они отстают на 6 часов и не содержат веб-хуков, это единственный доступный снимок. YP говорит, что ему сегодня лучше больше не запускать никаких команд, начинающихся с sudo, и передает управление JN.

2017/02/01 00:36 — JN: Делаю бэкап данных db1.staging.gitlab.com.


2017/02/01 00:55 — JN: Монтирую db1.staging.gitlab.com на db1.cluster.gitlab.com.

Копирую данные со staging /var/opt/gitlab/postgresql/data/ в production /var/opt/gitlab/postgresql/data/.


2017/02/01 01:05 — JN: nfs-share01 сервер выделен в качестве временного хранилища в /var/opt/gitlab/db-meltdown.


2017/02/01 01:18 — JN: Копирую оставшиеся production-данные, включая запакованный pg_xlog: ‘20170131-db-meltodwn-backup.tar.gz’.


2017/02/01 01:58 — JN: Начинаю синхронизацию из stage в production.


2017/02/01 02:00 — CW: Для объяснения ситуации обновлена страничка развертывания (deploy page). Link.


2017/02/01 03:00 — AR: rsync выполнился примерно на 50% (по количеству файлов).


2017/02/01 04:00 — JN: rsync выполнился примерно на 56.4% (по количеству файлов). Передача данных идет медленно по следующим причинам: пропускная способность сети между us-east и us-east-2, а также ограничение производительности диска на staging-сервере (60 Mb/s).


2017/02/01 07:00 — JN: Нашел копию нетронутых данных на db1 staging в /var/opt/gitlab_replicator/postgresql. Запустил виртуальную машину db-crutch VM на us-east, чтобы сделать бэкап этих данных на другую машину. К сожалению, она ограничена 120 GB RAM и не потянет рабочую нагрузку. Эта копия будет использована для проверки состояния базы данных и выгрузки данных веб-хуков.


2017/02/01 08:07 — JN: Передача данных идет медленно: по объему данных передано 42%.


2017/02/02 16:28 — JN: Передача данных закончилась.


Процедура восстановления

[x] — Сделать снимок сервер DB1 — или 2 или 3 — сделано в 16:36 UTC.

[x] — Обновить db1.cluster.gitlab.com до PostgreSQL 9.6.1, на нем по-прежнему 9.6.0, а staging использует 9.6.1 (в противном случае PostgreSQL может не запуститься).

Установить 8.16.3-EE.1.

Переместить chef-noop в chef-client (было отключено вручную).

Запустить chef-client на хосте (сделано в 16:45).

[x] — Запустить DB — 16:53 UTC

Мониторить запуск и убедиться, что все прошло нормально.

Сделать бэкап.

[x] — Обновить Sentry DSN, чтобы ошибки не попали в staging.

[x] — Увеличить идентификаторы во всех таблицах на 10k, чтобы избежать проблем при создании новых проектов/замечаний. Выполнено с помощью https://gist.github.com/anonymous/23e3c0d41e2beac018c4099d45..., который читает текстовый файл, содержащий все последовательности (по одной на строку).

[x] — Очистить кеш Rails/Redis.

[x] — Попытаться по возможности восстановить веб-хуки

[x] Запустить staging, используя снимок, сделанный до удаления веб-хуков.

[x] Убедиться, что веб-хуки на месте.

[x] Создать SQL-дамп (только данные) таблицы “web_hooks” (если там есть данные).

[x] Скопировать SQL-дамп на production-сервер.

[x] Импортировать SQL-дамп в рабочую базу.

[x] — Проверить через Rails Console, могут ли подключаться рабочие процессы (workers).

[x] — Постепенно запустить рабочие процессы.

[x] — Отключить страницу развертывания.

[x] — Затвитить с @gitlabstatus.



Возникшие проблемы

1. LVM-снимки по умолчанию делаются лишь один раз в 24 часа. По счастливой случайности YP за 6 часов до сбоя сделал один вручную.


2. Регулярные бэкапы, похоже, также делались только раз в сутки, хотя YP еще не выяснил, где они хранятся. Согласно JN они не работают: создаются файлы размером в несколько байт.

SH: Похоже, что pg_dump работает неправильно, поскольку выполняются бинарники от PostgreSQL 9.2 вместо 9.6. Это происходит из-за того, что omnibus использует только Pg 9.6, если data/PG_VERSION установлено в 9.6, но на рабочих узлах этого файла нет. В результате по умолчанию запускается 9.2 и тихо завершается, ничего не сделав. В итоге SQL-дампы не создаются. Fog-гем, возможно, вычистил старые бэкапы.


3. Снимки дисков в Azure включены для NFS-сервера, для серверов баз данных — нет.


4. Процесс синхронизации удаляет веб-хуки после того, как он синхронизировал данные на staging. Если мы не сможем вытащить их из обычного бэкапа, сделанного в течение 24 часов, они будут потеряны.


5. Процедура репликации оказалось очень хрупкой, склонной к ошибкам, зависящей от случайных shell-скриптов и плохо документированной.

SH: Мы позже выяснили, что обновление базы данных staging работает путем создания снимка директории gitlab_replicator, удаления конфигурации репликации и запуска отдельного PostgreSQL-сервера.


6. Наши S3-бэкапы также не работают: папка пуста.


7. У нас нет надежной системы оповещений о неудачных попытках создания бэкапов, мы теперь видим такие же проблемы и на dev-хосте.


Другими словами, из 5 используемых способов бэкапа/репликации ни один не работает. => сейчас мы восстанавливаем рабочий бэкап, сделанный 6 часов назад.

Инцидент с базой данных GitLab.com от 31/01/2017 Gitlab, Резервное копирование, Перевод, События, Происшествие, IT, Длиннопост

Заключение


Что показательно, ребята из GitLab сумели превратить свою грубейшую ошибку в поучительную историю, и, думаю, не только не потерять, но и завоевать уважение многих айтишников. Также за счет открытости, написав о проблеме в Twitter и выложив лог в Google Docs, они очень быстро получили квалифицированную помощь со стороны, причем, похоже, совершенно безвозмездно.


Как всегда, радуют люди с хорошим чувством юмора: главный виновник инцидента теперь называет себя "Database (removal) specialist" (Специалист по [удалению] баз данных), какие-то шутники предложили 1 февраля сделать днем проверки бэкапов http://checkyourbackups.work/



Оригинал https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCx...

Показать полностью 2

А вас поздравляли неизвестные люди?

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

Сонным голосом я ответил на звонок "Здравствуйте, кто говорит?". Из разговора выяснилось что девушки в тщетных попытках пытались дозвониться хоть до какого-нибудь человека, но их постигала неудача. Номер или не отвечал или не существовал. И только мой с кучей шестерок, оказался доступным. Девушки так радовались живому человеку, казалось их счастью не было предела. Они улыбались, веселились и поздравляли с праздником.


Девчата, кто бы вы ни были. С праздником вас. Я все же надеюсь, что в этот день вы все же осуществили свою мечты и смогли пообщаться и с другими людьми =)

Отдам сертификат на фотосессию.

Отдам сертификат на фотосессию. Екатеринбург, Фотосессия, Сертификат, Халява

Отдам безвозмездно, то есть даром, сертификат на 2000 рублей на фотосессию в студии Магистериум, г. Екатеринбург.

Данным сертификатом можно оплатить 100% стоимости "ФОТОСЕССИЯ «Классический портрет»" либо же скидка в размере стоимости сертификата на любую другую фотосессию.

Услуга включает в себя:

Работа фотографа со специальным освещением 30-40 кадров

аренда студии до 1 часа

запись всех фото на флешку клиента


Поскольку я не любитель фотографироваться, а выкидывать жалко, решил может кому и нужно. Сертификат презентовали при покупке в магазине (чек присутствует).

Срок действия сертификата до 2 января.

За ним вам придется приехать в район Дирежабля. Ибо вам надо, вы и забирайте =)

Показать полностью

Вопрос о газовых доводчиках/держателях дверей мебели.

Ситуация такая, купили как то шкаф в готором установлены на дверях газовые доводчики/держатели. Через пол года эксплуатации все доводчики сдохли, причем примерно одномоментно и резко, то есть прикрытии/закрытии перестало чувствоваться их сопротивлении и дверцу в открытом положении вообще не держат. Дверца открывалась примерно по 5 раз в день и фиксировалась в открытом положении пока вещи доставались/убирались в шкаф.


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

Можно ли как-то их оживить или придется покупать новые?


гуглом пользовался, ни чего путного не нашел, одна реклама.


фото прилагаю

Вопрос о газовых доводчиках/держателях дверей мебели. Держатель, Мебель, Вопрос, Помощь
Отличная работа, все прочитано!