Size: a a a

Архитектура ИТ-решений

2020 July 16

A

Alex in Архитектура ИТ-решений
Daria Kaftan
Коллеги, в четверг 16.07.2020 в 20:00MSK в zoom состоится доклад Александра Лучкова
"Непрерывное применение архитектурных практик как способ снижения рисков"

Аннотация
: Проблема документирования технических решений обсуждается часто, долго и с большими разногласиями. Широко распространены в зависимости от отрасли два лагеря "формалисты-бюрократы" и "гибкие-либералы".
Из моего опыта аргументы вторых сводятся к утверждениям  похожим на:
- "Документация устаревает быстрее, чем обновляется, поэтому в ИТ системе единственная актуальная документация - это код"
- "Документация нужна только там, где нужно её сдавать. Поэтому необходимо писать только ту документацию, которая указана в контракте"
- "Документация - это дорого и поэтому лучше делать продукт интуитивным"
- "Формализмы - это затраты на их изучение, а рынок настолько широк, что невозможно научить всех. Поэтому лучше писать каждый как умеет."

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

В рамках доклада я попробую обосновать свою точку зрения на причины возникновения подобных суждений, некоторые их риски и пути устранения этих рисков в духе применения принципов непрерывного приращения ценности результатов труда.
Продолжительность доклада:  ~45 минут доклад, ~30 минут обсуждение
Ссылка на конференцию: https://us02web.zoom.us/j/89019160706?pwd=dXF2ZFVFUWh2NDUwbTlaMFM3M09Xdz09
Идентификатор конференции: 890 1916 0706
Пароль: 513901
привет! А будет ли запись доклада?
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Alex
привет! А будет ли запись доклада?
Будет
источник

A

Alex in Архитектура ИТ-решений
Daria Kaftan
Будет
супер, спасибо! У нас к сожалению регулярный митинг по четвергам в 20 и пролетаю мимо докладов (
источник

YC

Yuriy Chervonyi in Архитектура ИТ-решений
Добрый день.
Хотел проконсультироваться, есть кластер postgresql под управлением patroni.
Стоит задача незамтено для приложений отправлять read запросы на реплики.
Из доступных вариантов пока только pgpool.
Но по результатам НТ пришлось поставить перед ним pgbouncer.
Мб есть лучше варианты?
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Alex
супер, спасибо! У нас к сожалению регулярный митинг по четвергам в 20 и пролетаю мимо докладов (
Я вот здесь http://youtube.com/mxsmirnov всё аккуратно складываю, что не забываем записать
источник

VS

Vasilyev Sergey in Архитектура ИТ-решений
Yuriy Chervonyi
Добрый день.
Хотел проконсультироваться, есть кластер postgresql под управлением patroni.
Стоит задача незамтено для приложений отправлять read запросы на реплики.
Из доступных вариантов пока только pgpool.
Но по результатам НТ пришлось поставить перед ним pgbouncer.
Мб есть лучше варианты?
В этом чЯтике немножко про другую "архитектуру" 😏
источник

I

Ilya in Архитектура ИТ-решений
Коллеги, добрый вечер! Никто не сталкивался с rocket.chat для внедрения внутрикорпоративного?  Или может быть у кого -то был опыт с другими месседжервми для решения задач локального развёртывания с доступом из инет сегмента?
источник

P

Paul in Архитектура ИТ-решений
Ilya
Коллеги, добрый вечер! Никто не сталкивался с rocket.chat для внедрения внутрикорпоративного?  Или может быть у кого -то был опыт с другими месседжервми для решения задач локального развёртывания с доступом из инет сегмента?
Добрый вечер, к сожалению - приходилось использовать. Опыт скорее отрицательный - удобство использования, уведомления, стабильность, это были далеко не плюсы этого изделия.
источник

I

Ilya in Архитектура ИТ-решений
Сможете написать про стабильность немного подробнее?
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Проблемный, но приемлемый. Использовали также Mattermost - проблемы были другие, плюсы-минусы другие, в целом примерно паритет.
источник

F

Fagor in Архитектура ИТ-решений
opensource в виде business application для enterprise — сразу нет
источник

F

Fagor in Архитектура ИТ-решений
в смысле проблем будет, в любом случае много, так еще и вы виноваты, ваш же выбор или рекомендация или внедрение
источник

F

Fagor in Архитектура ИТ-решений
opensource фреймворки, библиотеки, протоколы, даже компоненты — еще можно, но если законченное opensource business application — лучше избегать
источник

P

Paul in Архитектура ИТ-решений
Ilya
Сможете написать про стабильность немного подробнее?
Мобильный клиент лагает в части загрузки сообщений, бывают проблемы с вылетом приложения, есть проблемы с отображением новых сообщений (есть в уведомлении но нет в самом чате), десктопный клиент стабильней )
источник
2020 July 17

I

Ilya in Архитектура ИТ-решений
А может быть что посоветуете от себя? нужны веб, iOS , Android клиенты , on promises развертывание, с внешним пользователем, от 5000 пользователей . Плюс аудиовидео очень приветствуется
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Ilya
А может быть что посоветуете от себя? нужны веб, iOS , Android клиенты , on promises развертывание, с внешним пользователем, от 5000 пользователей . Плюс аудиовидео очень приветствуется
из enterprise решений есть express, но могу только предложить посмотреть. сильно рекламировать будет некрасиво с моей стороны, т.к. являюсь сотрудником компании)
источник

НК

Никита Конин (IPT)... in Архитектура ИТ-решений
Ilya
А может быть что посоветуете от себя? нужны веб, iOS , Android клиенты , on promises развертывание, с внешним пользователем, от 5000 пользователей . Плюс аудиовидео очень приветствуется
Почти наброс на вентилятор, но чем черт не шутит: https://biz.mail.ru/myteam/#premise
источник

SU

SinTpon Up here in Архитектура ИТ-решений
Ilya
А может быть что посоветуете от себя? нужны веб, iOS , Android клиенты , on promises развертывание, с внешним пользователем, от 5000 пользователей . Плюс аудиовидео очень приветствуется
Слак же
источник

SU

SinTpon Up here in Архитектура ИТ-решений
Alexander Luchkov
Считаем расходы по плану и по факту на контрольные точки. Если сходится  с приемлемым разбросом - всё в порядке.
А какой разброс считать приемлемым? Учитывать ли упущенную выгоду?
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
1. Зависит от ваших собственных оценок качества управления. В смысле должна же быть у вас статистика на тему "В скольких случаях конкретный управленец попадает в самим им составленный план". Исходя из реальности и прогноза можно построить "сколько вешать в %".

2. Упущеная выгода, на мой взгляд - это термин для "адвокатских разборок". В реальном управлении записывать её в "убытки" - это ошибочно. Если вы чего-то не сделали - значит не могли сделать.
Сам концепт был придуман для по-сути перекладывания ответственности за убытки с одних людей на других. Причём в случае управления - рассматривать упущенную выгоду, это как сказать "Я некомпетентный управленец, поэтому найду себе оправдание, что мне помешали, заставили, гады, упустить выгоду" )
источник