ГНИВЦ ФНС сообщает, что с начала 2018 года КЛАДР перестанет существовать и скачать его будет нельзя.

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

Правильные адреса нужны компаниям, которые любят своих клиентов. Знакомые банки, страховые и интернет-магазины, которые сейчас используют справочник КЛАДР, спрашивают нас, что же делать дальше. Поэтому мы запарились и написали пошаговое руководство по переходу с одних букв на другие от КЛАДР к ФИАС.

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

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

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

В нашем блоге мы рассказываем не только о развитии своего продукта — биллинга для операторов связи «Гидра», но и описываем сложности и проблемы, с которыми сталкиваемся на этом пути. Ранее мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему DoS.

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

В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий.

Недавно мы писали об использовании Clojure и MongoDB, а сегодня речь пойдет о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки.

Примечание переводчика: Мы в «Латере» занимаемся созданием биллинга для операторов связи. Мы будем писать об особенностях системы и деталях ее разработки в нашем блоге на Хабре, но почерпнуть что-то интересное можно и из опыта других компаний. Сегодня мы представляем вашему вниманию адаптированный перевод заметки инженера финансового стартапа Stripe о том, как его команда мигрировала огромное количество записей в базе данных.



Stripe для приема оплаты пользуется огромное количество продавцов, и недавно команда проекта завершила проект под названием «Очень большая миграция крупных объёмов данных между несколькими БД без потерь, остановок работы и ошибок в работе системы, отвечающей за ежедневную передачу огромного объёма финансов».

Как описал проект инженер Stripe Роберт Хитон: «Концептуально здесь все просто, но дьявол (и возможность спать по ночам) кроется в деталях».

Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 лет, и за это время поучаствовали более чем в 80 проектах внедрения.

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