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

Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.

Почему я считаю важным уметь менять парадигму технологического мышления?

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

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

О нас

Доброго времени суток, Хабр! Мы компания «Информационный центр». Наше основное направление – информационная безопасность (она же – ИБ). В ИБ мы занимаемся практически всем: аудитом, проектированием систем защиты, аттестацией, комплаенсом, пентестами, есть свой SOC, даже с гостайной работаем. Поскольку мы базируемся во Владивостоке, изначально мы работали больше в Приморском крае и в дальневосточных регионах страны, но в последнее время география наших проектов все дальше раздвигает немыслимые нами в момент основания границы.

В первой своей статье мы хотели бы рассмотреть такую сторону ИБ, как комплаенс (англ. complience – соблюдение, соответствие). И поговорим мы о том, что нужно сделать, чтобы полностью соответствовать российскому законодательству о персональных данных.

Когда читал книгу Impact Mapping первый раз, у меня было желание бросить её на середине. Всё, что там написано, слишком очевидно. Я нашел в себе силы и дочитал, благо книга коротная и с большими картинками. Как в последствии выяснилось, вся соль была в том, что все эти очевидные и простые практики из книги я не применял в своей работе.

Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.

Фреймворк скрам постепенно осваивают все большие по масштабам команды. Такой опыт есть и у нашей компании. Совместно с Unusual Concepts мы планируем поделиться своими наработками со всеми желающими в рамках дня Large-Scale Scrum — LeSS Day 2018, который пройдет 16 июля в офисе Comcity в Москве.

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

Этой статьей мы открываем серию публикаций о том, как автоматизировали в одном из крупных проектов компании ЛАНИТ процесс ручного тестирования большой информационной системы и что у нас из этого вышло.

Первая часть – организационно-управленческая – должна быть полезна в первую очередь тем, кто отвечает за автоматизацию тестирования и создает такие системы в целом. Руководители проектов, лидеры групп и владельцы сервисов функционального и автоматического тестирования, все, кого волнует вопрос «как построить экономически эффективное end-2-end тестирование своей ИТ системы», найдут здесь конкретный план и методику.

Источник

Технологии BI применяются бизнесом уже не один десяток лет. Однако сегодня с развитием облачных технологий, BigData и машинного обучения BI выходит на новый уровень. К чему это ведет и какими станут практики BI в ближайшие годы — читайте в нашем посте. Под катом — немного истории, актуальные тренды и результаты исследований.

Источник

Идея статьи родилась спонтанно из дискуссии в комментариях к статье «Кое-что об inode».



Дело в том, что внутренней спецификой работы наших сервисов является хранение огромадного числа мелких файлов. На данный момент у нас порядка сотен терабайт таких данных. И мы натолкнулись на некоторые очевидные и не очень грабельки и успешно по ним прошлись.

Поэтому делюсь нашим опытом, может кому и пригодится.

Доброго времени суток.

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

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

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

До моей работы в Uber у меня не было опыта работы с распределёнными системами. Я получил традиционное образование в Computer Science, после чего с десяток лет занимался full-stack разработкой. Поэтому, пусть я и мог рисовать различные диаграммы и рассуждать о компромиссах (tradeoffs) в системах, к тому моменту я недостаточно хорошо понимал и воспринимал концепции распределённости — такие, например, как согласованность (consistency), доступность (availability) или идемпотентность (idempotency).

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

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

Итак, давайте приступим к нашему погружению в SLA, согласованность, долговечность данных, сохранность сообщений, идемпотентность и некоторые другие вещи, которые мне потребовалось выучить на своей новой работе.

Время необходимое на прочтение 11 минут

Мы и Квадрат Гартнера 2019 BI :-)

Целью данной статьи является сравнение трёх ведущих BI платформ, которые находятся в лидерах квадранта Gartner:

— Power BI (Microsoft)
— Tableau
— Qlik

Рисунок 1. Gartner BI Magic Quadrant 2019

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

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

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

Выделим несколько направлений для анализа и оценим по 3 бальной системе:

— Порог вхождения и требования к аналитику;
— Источники данных;
— Очистка данных, ETL (Extract, Transform, Load)
— Визуализации и разработка
— Корпоративная среда — сервер, отчеты
— Поддержка мобильных устройств
— Embedded (встроенная) аналитика в сторонние приложения/сайты

Процесс документирования эволюционно прорастает из скупых комментариев в коде по мере роста компании. Где-то в середине пути обычно появляются люди, которые говорят, что знают, как правильно, и что «в этой книжке написано, как надо делать документацию», и приносят в компанию какой-нибудь тяжелый процесс. Дальше идут обсуждения, споры, ссылки на разные источники с противоречивыми подходами и так далее. На самом деле всё это не случайно. Каждый раз, когда мы сталкиваемся с такими моментами, это значит, что есть культурные различия. Тренды меняются, и каждая эпоха дает свои учебники.

Под катом вместе с Максимом Цепковым будем разбираться, какие уроки можно вынести из разных подходов, как проектировать документы проекта, что занести в wiki, для чего подойдет Google Docs, а что обязательно должно все время находиться перед глазами. Да и вообще, зачем нужна это вся документация. Заодно и тему управления знаниями затронем.

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

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

Выпущенный в ноябре 2018 года AresDB представляет собой инструмент анализа в реальном времени с открытым исходным кодом. Он использует нетрадиционный источник питания, графические процессоры (GPU), что позволяет увеличивать масштаб анализа. Технология GPU, перспективный инструмент анализа в реальном времени, за последние годы значительно продвинулась, что делает ее идеальной для параллельных вычисления в реальном времени и обработки данных.

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

Идея написать данную статью возникла после прочтения вышедшей на днях статьи Эффективные личные финансы. Уровень 1. В ней озвучены очень правильные мысли, но в основе лежит необходимость ведения финансового учета, который нужно вести весьма кропотливо и постоянно, а анализ проводить постфактум, когда деньги уже потрачены. Ранее я дважды делал попытки вести финансы подобным образом и мотивация кончалась уже через пару месяцев.

В данной статье я расскажу о способе ведения финансов, который использую уже продолжительное время. Он требует меньше усилий и позволяет быстрее оценить (не)эффективность своих трат.

Ведя бюджет описанным в статье способом можно:

1. Ответить на вопрос «почему я неплохо зарабатываю, но в конце месяца у меня всегда ноль?»
2. Быстро определить и устранить неэффективные траты
3. Накопить резервный капитал
4. Подойти вплотную к составлению капитала для инвестиций.

Вопрос обеспечения информационной безопасности Государственных Информационных Систем не только не теряет актуальности, но с развитием концепции электронного правительства и увеличением количества электронных услуг, становится более значимым. Так, около месяца назад большой резонанс на Хабрахабре вызвала статья «И так сойдёт… или как данные 14 миллионов россиян оказались у меня в руках».

Используя терминологию проекта документа «Методика определения угроз безопасности информации в ИС», эту ситуацию потенциально можно описать следующим образом:

Улучшаем дизайн проекта с помощью тактически грамотных действий, а не таланта.

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

Возможно, в компании, в которой вы работаете, нет штатного дизайнера, и вам необходимо реализовать интерфейс для нового функционала. Или, может быть, вы решили подработать на побочном проекте, и хотели бы, чтобы он выглядел лучше, чем «ещё один bootstrap-сайт».

Легко опустить руки и сказать: «Я никогда не смогу сделать это должным образом, я не художник!», Но, оказывается, есть уйма ловких приёмов, которые вы сможете использовать, чтобы поднять свою работу на другой уровень, не имея опыта в графическом дизайне.

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

1. Для создания иерархии используем цвет и вес вместо размера

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

Еще 4 года назад использование контейнеров в production было экзотикой, но сейчас это уже норма как для маленьких компаний, так и для больших корпораций. Давайте попробуем посмотреть на всю эту историю с devops/контейнерами/микросервисами ретроспективно, взглянуть еще раз свежим взглядом на то, какие задачи мы изначально пытались решить, какие решения у нас есть сейчас и чего не хватает для полного счастья?

Я буду в большей степени рассуждать про production окружение, так как основную массу нерешенных проблем я вижу именно там.

Продолжаем рассказывать историю Atlassian. 1 часть вы можете прочитать тут.

2015 год — настоящее время: расширение на прибыльные конкурентные рынки

Для многих SaaS-компаний сегодняшний бизнес Atlassian выглядит как «конечная цель»: вырасти в огромную работающую на мировом рынке публичную компанию со сложным набором интегрированных продуктов для самых разных команд.

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

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

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

Переведено в Alconost

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